Inscription : 28 Mai 2010, 11:34 Message(s) : 99 Localisation : Eteauville, France
Bonjour,
Je sais que le sujet a été évoqué à maintes fois, mais j'aimerais juste avoir votre avis sur cette routine. A noter que la largeur d'écran est de 128 pixels :
Inscription : 28 Mai 2010, 11:34 Message(s) : 99 Localisation : Eteauville, France
même routine, mais façon "masque". Elle est plus gourmande que la version précedente, autant en termes de temps d'execution que de mémoire.
Par contre, la transparence est parfaite (au pixel près)
Code :
void sprite_8x16_mask_draw(tSprite8x16* pSprite) { __asm ;; load IX with sprite information ld l,4 (ix) ld h,5 (ix) push hl pop ix
; calculate sprite screen adress in hl ld hl,#_aScreenLinesOffset ld e,1(ix) ld d,#0 rl d rl e add hl,de ld a,(hl) ld e,a inc hl ld a,(hl) ld d,a push de pop hl ld e,0(ix) ld d,#0 add hl,de
; load de with adress to sprite data ld e,2(ix) ld d,3(ix)
ld bc,#0x0208 sprite_draw_mask_loop: ;; ld a,(de) and (hl) inc de ld (hl),a ld a,(de) or (hl) inc de ld (hl),a inc hl ;; ld a,(de) and (hl) inc de ld (hl),a ld a,(de) or (hl) inc de ld (hl),a inc hl ;; ld a,(de) and (hl) inc de ld (hl),a ld a,(de) or (hl) inc de ld (hl),a inc hl ;; ld a,(de) and (hl) inc de ld (hl),a ld a,(de) or (hl) inc de ld (hl),a
ld a,l add #0xfd ld l,a ld a,h adc #0x7 ld h,a dec c jp nz,sprite_draw_mask_loop ld c,#0x08 ld a,l add #0x40 ld l,a ld a,h adc #0xc0 ld h,a dec b jp nz,sprite_draw_mask_loop __endasm; }
Hum, si j'ai a peu près pigé la première routine, je ne vois pas trop l'intérêt de faire un test pour vérifier si un octet du sprite a une valeur 00. Il est plus rapide de recopier simplement systématiquement les valeurs. L'usage de LDI dans ce cas présent semblerait approprié, mais il faudrait alors modifier pas mal de choses dans la routine.
Sans tout chambouler, on peut aussi gagner un petit peu de temps en partant du principe que les sprites ont une taille paire et commencent à une adresse ram paire. Une fois sur deux, on peut utiliser alors un INC E au lieu de INC DE car on est alors sûr qu'il n'y a pas de risque de débordement.
Inscription : 28 Mai 2010, 11:34 Message(s) : 99 Localisation : Eteauville, France
Je me pose des questions sur l'efficacité de mon code. En gros, l'affichage d'un sprite de 8x32 (8 pixels / 32 lignes) en mode 0 dure quasiment la moitié d'une trame, ce qui limite sévèrement le nombre de sprites par trame.
J'ai merdé quelque part ? J'optimise comme un boeuf ou c'est normal ?
Voila une capture pour illustrer le timing :
- vert on restaure l'arrière plan qui aurait pu être écrasé par les sprites de la trame précédente - jaune on sauvegarde l'arrière plan pour la trame courante - vert j'affiche le sprite de 8x32 en transparence (technique du masque avec un tableau de précalcul de 256 octets) :
Inscription : 20 Août 2007, 18:21 Message(s) : 4992
si c'est le timing pour l'affichage de tout ces sprites , je trouve pas ca enorme.. en comptant les pixels de tes tiles je suis a 8x16 pixel ou 4x16 octets ..
Inscription : 28 Mai 2010, 11:34 Message(s) : 99 Localisation : Eteauville, France
non non, les tiles ici (les murs) ne sont affichés qu'une seule fois, et ne comptent pas dans le timing. Il y a bien un sprite de 8x32 (4 octets/32 lignes en mode 0) d'affiché, mais masqué par un problème de synchro avec la vbl.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Donc pour répondre à ta question , pour un format de 4*32 octets je trouve ça effectivement lent.A mon avis avant de voir pour optimiser ton code , il faut peut être revoir le format de tes données.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 60 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum