I love my CPC (+)

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

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...

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...

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 ?

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 ?

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 !