Merci pour vos commentaires, c'est très motivant.
Ces derniers jours j'ai revu la structure de données pour stocker les "image set".
ça fonctionne très bien et offre de nouvelles possibilités en terme de fluidité d'affichage.
Quand on assigne une image à un sprite, on le fait comme ça:
Code:
ldd #Img_SonicWalk
std image_set,u
ldb #$01
stb priority,u
ldd #$807F
std xy_pixel,u
Dans le fichier properties de l'objet on a :
Code:
sprite.Img_SonicWalk=./Sonic2/Objects/TestImageSet/Sonic_017.png;NB0,NB1,XB0,XB1,YB0,YB1,XYB0,XYB1
On y retrouve l'étiquette et un ensemble de codes en seconde position de paramètre qui demande au builder de générer des variantes de sprites compilés.
Voici la signification des codes:
Code:
# NB0 : no flip, background backup / draw / erase compilated sprite, no x offset
# ND0 : no flip, draw compilated sprite, no x offset
# NB1 : no flip, background backup / draw / erase compilated sprite, 1px x offset
# ND1 : no flip, draw compilated sprite, 1px x offset
# XB0 : x flip, background backup / draw / erase compilated sprite, no x offset
# XD0 : x flip, draw compilated sprite, no x offset
# XB1 : x flip, background backup / draw / erase compilated sprite, 1px x offset
# XD1 : x flip, draw compilated sprite, 1px x offset
# YB0 : y flip, background backup / draw / erase compilated sprite, no x offset
# YD0 : y flip, draw compilated sprite, no x offset
# YB1 : y flip, background backup / draw / erase compilated sprite, 1px x offset
# YD1 : y flip, draw compilated sprite, 1px x offset
# XYB0 : xy flip, background backup / draw / erase compilated sprite, no x offset
# XYD0 : xy flip, draw compilated sprite, no x offset
# XYB1 : xy flip, background backup / draw / erase compilated sprite, 1px x offset
# XYD1 : xy flip, draw compilated sprite, 1px x offset
Dans le cas ci dessus, le moteur de jeu va utiliser un sprite compilés pour les position x "pair" et un autre dans le cas d'une position x "impaire" .
Si on retire les balises qui se terminent par un 1 dans la configuration, le moteur considère qu'il n'y a pas de différence de position et x=0 sera pareil que x=1, on ne rafraichit rien.
La définition ci dessus permet également de basculer le sprite facilement sur des variantes "miroir" :
Code:
lda render_flags,u
eora #render_ymirror_mask
sta render_flags,u
Un simple changement de bit et le moteur se charge de rétablir le fond en respectant les priorité de sprites, affiche le sprite mirroré et declenche le rafraichissement des sprites en collision au dessus.
De la même manière on peut passer d'un sprite compilé avec sauvegarde de fond à un sprite compilé sans sauvegarde.
Code:
lda render_flags,u
ora #render_overlay_mask
sta render_flags,u
La désallocation des données de fond sauvegardées pour le précédent sprite est maintenant bien effectuée: ouf !
L'inverse fonctionne aussi, on peut repasser en sprite compilé avec sauvegarde si on pass le flag overlay à 0.
Si on fait appel à une image qui n'existe pas dans "l'image set" (ex: on veut un mirroir X mais on ne l'a pas déclaré dans le properties) : le moteur de jeu efface l'image actuelle si elle existe et n'affiche rien en remplacement, le moteur continue sans planter (ce qui n'était pas le cas semaine dernière).
Toutes ces nouvelles fonctions n'ont quasiment pas d'impact sur les perfs, l'algo du moteur va même dans le sens de la simplification, çe qui est bon signe.
Pour encoder l'index de données pour cet ensemble de sprites compilés relatifs à une image j'ai créé la structure suivante:
Fichier(s) joint(s):
TO8 game engine-Data Structures-ImageSet.png [ 149.38 Kio | Vu 6541 fois ]
Pour que cette structure n'occupe pas trop de place (imaginez avec 400 sprites ...), elle est de taille variable.
les lignes "mapping_frame" qui ne sont pas utiles ne sont pas écrites dans cette structure.
On joue sur les offsets en bleu pour indiquer au moteur su le mapping_frame est absent (offset:0) ou s'il existe à quel offset le trouver.
La première ligne contient 4 offsets pour chaque mode mirroir.
Chaque mode mirroir a de nouveau 4 offsets pour le mode normal/overlay et le décalage d'un pixel.
Un "image set" avec une seule image donne donc :
Code:
Img_star_4
fcb $06,$00,$00,$00,$0A,$16
fcb $06,$00,$00,$00,$FB,$F5
fcb $08,$A0,$00,$09,$A0,$00,$01
Gros gain de place ...
Un dernier dessin pour expliquer X1, Y1, x_size, y_size:
Fichier(s) joint(s):
TO8 game engine-Sprite Coordinates.png [ 63.08 Kio | Vu 6541 fois ]
Le sprite est positionné par des coordonées xy centré sur l'image (pixels transparents compris).
Pour détecter les collisions (dans le moteur d'affichage) et les sorties d'écran, on utilise l'offset et la taille réelle du sprite (hors pixels transparents).
Dernier truc codé hier soir mais je n'ai pas trop le temps de détailler :
Ajout d'un player PCM au moteur avec lecture d'un sample sur plusieurs pages de RAM.
Définition dans le properties:
Code:
sound.Pcm_SEGA=./Sonic2/Objects/SEGA/SEGA.bin
exemple d'appel :
Code:
ldy #Pcm_SEGA
jsr PlayPCM
SEEGAAA