Bien fait !

ACID ! ( ou l'avenir de Wildfire)

2009-10-29T11:57:00.001-07:00

J'ai découvert récemment qu'on pouvait trouver le fameux composant nécessaire à la production de nouvelles cartouches pour AMSTRAD+ & GX4000 : l'ACID !
Ce composant est la clef de voute de la protection de chez AMSTRAD et semblait introuvable jusqu'ici , en tous cas pour moi.Il s'agit de la petite puce à 16 pattes au dessus de l'eprom sur la photo (ici Burnin' Rubber étiquette rouge)

Cela remettait totalement en cause mon approche pour le projet Wildfire. En effet, la machine visée pour ce projet était un Amstrad+ avec 128K de RAM et un lecteur de disquette ou autre périphérique de stockage de masse équivalent, ce qui excluait d'emblée le 464+ stock et la GX4000.

Une cartouche permettrait un stockage théorique de 32 banques de 16K soit 512K.De plus, contrairement à la RAM , les pages de ROM de la cartouche ne se connectent pas sur le même segment mémoire que l'ASIC ce qui serait un avantage indéniable en terme d'animation des sprites.

En considérant ces aspects techniques et la disponibilité de l'ACID , je compte finalement développer ce projet en version cartouche et proposer une version EPROM seule pour les propriétaire de cartouches capable de l'accueillir.
Reste tout de même quelques inconnues, notamment à propos des fameux 6 "LK" qu'on peut voir sur la photographie au dessus ainsi que leur configuration avec une EPROM 512K.Reste aussi à résoudre le problème de la production de la partie plastique de la cartouche.Néanmoins je reste optimiste et je pense que chaque problème sera règlé en son temps.

En attendant d'acquérir le matériel nécéssaire , il me reste toujours à terminer Rick128+.Restez branchés pour la suite !

petite update

2009-10-17T16:56:00.000-07:00

J'ai eu un peu le temps et le courage de travailler par ce beau (sic) week-end d'astreinte.Voilà donc l'apparence finale de notre bon vieux Rick avec son nouveau HUD.Pour le score, j'ai opté pour une fonte irrégulière afin de souligner le coté "cartoon".
Ne manque plus que la page de menu ainsi que l'écran de chargement (en fullscreen d'ailleurs) pour compresser le tout et écrire le loader.

Et merde...

2009-10-07T00:35:00.000-07:00

Comme ça passe vite, 33 ans aujourd'hui !

Et pis une petite série qui m'a bien fait rire :

Chez Claude André: Jésus : Juif ?

J'adore !

2009-09-27T04:34:00.000-07:00

Ca fait dèjà quelque temps que cette vidéo a été postée mais je ne résiste pas au plaisir de la poster ici.Enjoy !

Plus de place sur mon bureau !

2009-09-20T09:12:00.001-07:00

Et voilà, après l'installation sur mon bureau, entre mon 6128 (CRTC type 2, lecteur 3" ,GT65 , bientôt un CTM644 et un 3"5 externe) , mon vieux PC d'où je poste ce message et mon 6128+ ( lecteur 3"5 interne ) , je me demande où je vais mettre ma prochaine acquisition.

Il va me falloir un bureau plus grand !

Enfin !

2009-09-17T03:43:00.000-07:00

C'est après des mois d'attente que j'ai enfin le fameux Orion Prime entre les mains.Je ne vous en dirais pas plus sur le jeu en lui même avant sa distribution grand public le 28 Octobre 2009 mais je vous laisse admirer le packaging moderne et soigné surtout pour un jeu visant une machine de 25 ans !

La boite en elle même , format DVD.

L'intérieur, avec à droite le jeu au format 3"5 (il était dispo aussi au format 3") avec en dessous les négatifs des caméras de surveillance et à gauche, un extrait de journal et un mini-cd contenant les enregistrement audios.

Wildfire sur CpcWiki

2009-09-09T10:26:00.000-07:00

Vu que ce que j'avais posté sur CPCrulez à propos de Project Wildfire avait fait un peu le tour des sites CPC, j'ai complété sa page sur le CPC wiki, c'est là : Project Wildfire

I love my CPC (+)

2009-09-09T10:09:00.000-07:00

Certes, ça sent un peu le réchauffé mais en attendant Orion Prime (à partir du 16 Septembre) , me voilà en train fignoler la version CPC+ de notre bon vieux Rick Dangerous (code original de 1989!). Actuellement, j'en ai pratiquement fini, me manque juste un HUD digne de ce nom.Parlons peu, voici quelques shots en attendant la release (avec code source svp)

Je me suis permis un petit lifting de notre héro pour coller un peu plus avec la version 16 bits (version originale à gauche).

Le nouveau menu avec les toutes nouvelles options et même un sound test !

Au final, pour cette nouvelle version, vous retrouverez :

Des samples tirés de la version Amiga en 15Khz
Des intros pour chaque niveau proches de la version Amiga
Des musiques tirées de la version Atari ST
Et quelques surprises notamment au niveau Gameplay !

A bientôt pour la release (enfin si je survis à Orion Prime !)

Project Wildfire

2009-04-18T15:12:00.000-07:00

Toujours aussi peu bavard car manquant de temps libre et parfois aussi d'inspiration, je vais quand même poster un petit shot de mon travail actuel.Je viens de passer quelques heures à débuguer mon code pour CPC+ car après l'avoir optimisé , ce dernier ne voulait pas fonctionner comme prévu... ...pour cause de bout de code trop rapide !
Enfin bref, c'est règlé et voilà le petit shot promis avec ce logo en 6 couleurs avec raster svp (merci PRI !)

Et vive le rétro(pro)gaming !

De retour...

2008-12-05T03:57:00.000-08:00

Après un long temps sans poster ni même pouvoir travailler je suis de retour.Du coup, je me suis remis au boulot et voici un petit shot de ce qui avance, un éditeur de sprites OpenGL pour mon projet en cours.Certes tout bête, tout con mais faut quand même l'écrire !

Nouvel indice...

2008-09-22T06:16:00.000-07:00

Ca avance mais comme je réecris tout depuis le début, il n'y a pas encore de résultat réelement visible.Allez, un indice tout de même (celui qui trouve,je lui paye la pizza (sauf rasko !))

Quoi de neuf ?

2008-09-13T07:06:00.000-07:00

Ba oui, ça fait un mois que je n'ai rien posté et pour cause, je n'ai pas beaucoup de temps à moi !

Un nouveau projet commencé mais lequel ? héhé

Et voici le petit monstre qui me vole tout mon temps !

Une approche tout shader ?

2008-08-13T04:57:00.000-07:00

Je commence à réflechir sur les techniques que l'on pourrait utiliser pour rendre de la 2d avec GLSL.
Bien que cela puisse être discutable, il me semble plus interessant d'utiliser des graphismes palettisés plutôt que en couleurs vraies.Tout d'abord, les jeux originaux utilisent peu de couleurs, entre 2 et 16 pour le CPC (31+1 transparente pour le CPC+), 4096 au maximum pour l'amiga, les consoles et les machines arcade utilisent des palettes locales pour les sprites et les arrières plans (généralement 16couleurs).

D'où une définition du nombre de couleurs qui me semble raisonnables serait :

256 couleurs par sprites
256 couleurs par plan de parallax

Techniquement, la gestion des sprites est limite triviale.Les sprites partageant la même palette sont stockés sur la même image 8bits stockée comme texture2D dans un format à une composante (GL_R par exemple).La palette est une texture1D au format RGBA de dimensions 256*1.Ne reste plus qu'a afficher le sprite sous forme de GL_QUAD, GL_TRIANGLES ou encore GL_TRIANGLE_STRIP/FAN avec un shader dans des conditions spécifiques:

Unit0 : texture2D,table de sprite, filtre : GL_NEAREST
Unit1 : texture1D, palette, filtre : GL_NEAREST

Le shader recupère la donnée sur l'unité de texture 0 et s'en sert comme coordonées de texture du l'unité de texture 1 où il recupère la bonne couleur.

Pout la gestion des plans de parralax, l'idée est aussi simple mais la nature même des plan rend difficile l'utilisation directe sous forme de texture.Les machines utilisant les sprites Hardware 'découpent' les élements graphiques (généralement 16*16), cette technique se prête assez bien à mon projet et on peut utiliser un index pour supprimer les parties redondantes.Donc on a le set de données suivant :

Une texture 2d contenant les morceaux du plan (tiles)
Une palette RGBA de ce plan
Une table d'index contenant l'agencement des tiles

On pourrait alors en utilisant la table d'index calculer chaque tile à afficher et envoyer le tout au shader mais j'ai dans l'idée une autre approche :

Unit0 : texture2D,table de tiles, filtre : GL_NEAREST
Unit1 : texture1D, palette, filtre : GL_NEAREST
Unit2 : table d'indexes, filtre : GL_NEAREST

En utilisant les textures de coordonées et les variables uniformes, on pourrait donner au shader les informations sur où commencer dans la table d'indexes, la taille, etc... Il n'y aurait plus qu'à dessiner un GL_QUAD de la taille l'écran affichable pour afficher le plan.

Avec cette technique, tout le travail d'affichage, du calcul de géométrie jusqu'au dessin en lui même serait confié au shader, d'où mon titre.

Voilà, maintenant ce n'est pas tout d'avoir exposé cette idée, il va falloir l'implementer.Ne me reste plus qu'a trouver quelques sprites et quelques 'backgrounds' et let's get busy !