routine de sprites

neocps1

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 :

merci !

Code :

typedef struct
{
   unsigned char x, y;
   unsigned char* pData;
}
tSprite8x16;


void sprite_8x16_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_loop:
sprite_next_pixel_0:
   ld   a,(de)
   inc de
   or   a
   jp   z, sprite_next_pixel_1
   ld   (hl),a
sprite_next_pixel_1:
   inc hl
   ld   a,(de)
   inc de
   or   a
   jp   z, sprite_next_pixel_2
   ld   (hl),a
sprite_next_pixel_2:
   inc hl
   ld   a,(de)
   inc de
   or   a
   jp   z, sprite_next_pixel_3
   ld   (hl),a
sprite_next_pixel_3:
   inc hl
   ld   a,(de)
   inc de
   or   a
   jp   z, sprite_next_row
   ld   (hl),a
sprite_next_row:
   ld   a,l
   add   #0xfd
   ld   l,a
   ld   a,h
   adc #0x7
   ld   h,a
   dec   c
   jp   nz,sprite_draw_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_loop

   __endasm;
}

neocps1

j'ai oublié de préciser que cette routine ne permet d'afficher que des sprites de 8x16 en mode 0 :sweatingbullets:

neocps1

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;
}

markerror · **Inscription :** 04 Sep 2007, 19:43 **Message(s) :** 739

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.

neocps1

Je teste si la valeur est 0 pour gérer la transparence

hERMOL

en mode 0 -> 1 octet = 2 pixels , alors ton test n'est pas complet..

le pavé sur le création de sprites et animation de MICHEL MAIGROT , devrais t'intéresser. Ca réponds aux question que tu te pose --> https://cpcrulez.fr/coding_graphic-09-cr ... __SOSP.htm

neocps1

tout à fait, par contre le test est juste avec la deuxième version.
Dommage que ça double la quantité de mémoire nécessaire par sprite.

neocps1

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) :

Megachur · **Inscription :** 12 Juin 2008, 20:29 **Message(s) :** 1726

voilà pourquoi les concepteurs de consoles et d'ordinateur sont rapidement allés vers le développement de sprites 'hard' !

comme c'est pas le cas sur le cpc old, il va falloir que tu optimises et/ou limite le nb de sprites affichés à l'écran !!!

mais je suis sûr qu'on pourra t'aider !

:mdr:

neocps1

oui, mais ca te parait déconnant le temps que prennent mes routines ou pas ?

fano

8*32 , c'est 8 pixels ou 8 octets ?

hERMOL

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

neocps1

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.

fano

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.

neocps1

quelques conseils ? :oops:

routine de sprites

Qui est en ligne ?