merci Yoann,
Pas la grande forme aujourd'hui mais je vous avais promis des explications avant fin de semaine, alors voila ;-)
Le constat :
- La map de R-Type 128K pour CPC a un arrière plan uni
- le scroll a mettre en place est assez lent
Partant de ce constat, voici la stratégie :
Etape 1 :
- préparer une map et mettre en transparence les pixels qui se suivent lors d'un scroll à gauche (j'avais déjà un outil pour faire ça dans toutes les directions)
On obtient donc ça (je n'ai pas mis toute la map car l'image est trop grande pour une pièce jointe, donc juste le début mais imaginez ça pour tout le niveau) :
Fichier(s) joint(s):
rtype-map.png [ 3.4 Kio | Vu 17620 fois ]
- quand on va scroller les tiles vont effacer leur trace grace à la bordure noire à leur droite.
- de même si dans le tile, deux pixels de la même couleur se suivent, on positionne de la transparence sur ceux de droite.
comme on a cette transparence il faut init le fond de départ avec une image pour combler ces trous, elle est compressées en RAM par RLE et prend 2Ko environ :
Fichier(s) joint(s):
0.init.png [ 1.67 Kio | Vu 17620 fois ]
On retrouve les pixels noirs du fond et ceux répétés horizontalement dans les tiles. Elle ne sert qu'a l'init, après les tiles "balayent" eux même derrière eux pour rétablir le fond noir.
Au final on économise donc l'affichage de pas mal de tiles car transparents (pas besoin de réécrire le fond à chaque fois.
une fois la map prête on génère le tileset.
Etape 2 :
- générer les données de la map (index de tiles), ici on va réutiliser le système de buffer mis en place dans Sonic.
Comme la map est petite, on peut directement sauver la page et l'adresse des tiles directement dans le buffer et ce pour la map entière (2560 octets de mémoire)
Ainsi pas de remplissage de buffer a faire au fur et à mesure de l'avancement dans la map. (J'ai agrandi le buffer un petit peu car il était de 2Ko initialement)
- on fait la même chose avec des tiles décalés de 1 pixel, donc un second buffer et second tileset
- attention on conserve systématiquement les pixels par paire dans le cas de la transparence ou du décalage de 1 pixel. Ceci afin d'éviter d'avoir a faire du masquage des octets (2 pixels dans un octet).
Cette remarque est valable pour le traitement en Etape 1 également.
Etape 3 :
- la vitesse de scroll étant lente on ne va pas rafraichir le scroll toutes les frames, voici la séquence :
A1 A2 x1 x2 B1 B2 x1 x2 A1 A2 x1 x2 B1 B2 ...
A1 : en buffer vidéo 1 : restauration du fond pour les sprites, écriture des tiles, sauvegarde du fond pour les sprites, écriture des sprites
A2 : en buffer vidéo 2 : restauration du fond pour les sprites, écriture des tiles, sauvegarde du fond pour les sprites, écriture des sprites
x1 : en buffer vidéo 1 : restauration du fond pour les sprites, sauvegarde du fond pour les sprites (nouvelle position), écriture des sprites
x2 : en buffer vidéo 2 : restauration du fond pour les sprites, sauvegarde du fond pour les sprites (nouvelle position), écriture des sprites
B1 : idem A1 mais avec le tileset dont les images sont décalées de 1
B2 : idem A2 mais avec le tileset dont les images sont décalées de 1
...
Evidement pour les deux premiers A1 et A2 il n'y a pas de fond de sprite à restaurer puisque non affichés.
Au final j'ai réutilisé le code existant du scroll de sonic sur la partie buffer, le reste existait déjà.
Connexion
M’enregistrer
FAQ
Rechercher
Ben... heu... non 
de la QA)
