Meilleurs algo d'un test par bouding box

Tu es bien obligé de le faire à un moment ou un autre.Tu inclues ta routine de test dans la routine qui gère les enemis ce qui t'évites de devoir construire une liste.Il peut très bien faire pareil sans faire aucun traitement spécifique.ça ne change rien au fond du problème.

Moi je procède comme suit, je dis pas que c'est forcement mieux, a vous de juger .
j'ai les stuctures de mes sprites (ennemis, bullets) en ram .
Un pointeur pointe sur le début de la liste .

Parcoure la liste jusqu'à la fin
si le sprite est inactif -> sprite suivant
si sprite = 1 -> test collision
    -> collision = 0 on déplace le sprite
  -> collision à 1 on initialise un pointeur de la struc vers fonction (explosion par exemple)
on lance la fonction alternative (explosion) du sprite

Passe au sprite suivant.

TOUKO a écrit:C'est un peu ça l'idée .
Sa routine est super rapide, mais nécessite des traitements avant/après .
Les nôtres sont plus lentes, mais pas de traitement .

et comme je l'ai souligné plus haut :
de plus si je dis pas n'importe quoi, plus il y a de collisions plus sa routine est lente ..
Car à chaque collision il fait 116+124+20/24, donc c'est très variable, ajoutez ça aux traitements post/pré .

Mais le but justement c'est d'appeler cette routine un minimum de fois puisqu'elle traite une liste de sprites. Oui y'a un init, mais comme toi tu dois initialiser tes variables bouding_box et sprite que tu utilises en dur dans ta routine. Ca revient exactement au même...

Sinon je suis déçu, j'ai réussi à descendre à 120 cycles / loop mais pas plus bas pour le moment :-/

si sprite = 1 -> test collision

Tu fais ton test de collision avec plusieurs sprites normalement non ? c'est ici qu'intervient la fonction qu'on implémente justement.

Par contre je viens de relire ton code de Stef, il y a un problème non ?

Il me semble que dès que tu trouves une condition de "non-collision" tu branches au label .no_collid, où tu places 0 dans le registre d0 (la valeur de retour je pense) et tu sors de la routine (rts)   

Tu devrais plutôt boucler sur le prochain sprite plutôt que de sortir, à mon sens...

Mais le but justement c'est d'appeler cette routine un minimum de fois puisqu'elle traite une liste de sprites. Oui y'a un init, mais comme toi tu dois initialiser tes variables bouding_box et sprite que tu utilises en dur dans ta routine. Ca revient exactement au même...

Je sais je vois ça, mais c'est une donnée aléatoire, car tu peux pas savoir combien de sprites vont entrer en collision, et ta routine est a 120 cycles constant seulement si 0 sprites sont en collision.
Puisque à chaque collisions tu sors, c'est bien ça ??

Tu fais ton test de collision avec plusieurs sprites normalement non ? c'est ici qu'intervient la fonction qu'on implémente justement.

Oui bien sur, je fais ça ..
Mais ça change rien, tu es bien obligé de préparer toutes les données en amon, moi pas .
Et comme dit plus haut, plus il y a de collisions, moins ta routine est efficace .

vingazole a écrit:Par contre je viens de relire l'algo de Stef, il y a un problème non ?

Il me semble que dès qu'il trouve une condition de "non-collision" il branche au label .no_collid, où il place 0 dans le registre d0 (la valeur de retour je pense) et il sort de la routine (rts)   

Il me semble qu'il devrait plutôt boucler sur le prochain sprite plutôt que de sortir...

Heu, ouais carrément X'D   J'ai repris le code de base sans faire attention, en gros faut juste que j'inverse tout les tests :p

TOUKO a écrit:Moi je procède comme suit, je dis pas que c'est forcement mieux, a vous de juger .
j'ai les stuctures de mes sprites (ennemis, bullets) en ram .
Un pointeur pointe sur le début de la liste .
Parcoure la liste jusqu'à la fin
si le sprite est inactif -> sprite suivant
si sprite = 1 -> test collision
    -> collision = 0 on déplace le sprite
  -> collision à 1 on initialise un pointeur de la struc vers fonction (explosion par exemple)
on lance la fonction alternative (explosion) du sprite

Passe au sprite suivant.

On parle exactement de la même chose, sa méthode reste valable pour cette approche.De plus , comme j'ai dit il peut très bien réserver 4 registres pour stocker ses variables de joueur (ou alors utiliser un registre d'adresse pour pointer dessus) pour tous les enemis, ce qui est largement moins couteux que d'aller chercher en mémoire ces variables à chaque fois.

L'autre méthode (traitement1(sprites, num);traitement2(sprites, num);traitement3(sprites, num) coute évidemment la construction d'une liste (ou simplement le fait d'utiliser 1 bit comme flag dans une structure commune ce qui est encore moins "cher" que de construire une seconde liste) mais peut se révéler payant dans le cas de routines où tu optimises au maximum l'utilisation des registres.

Bah non, les boucles c'est lent, moins tu en fais mieux c'est .
Mais je comprends ce que tu veux dire, c'est vrai que dans ton cas de CPU ça peut être utile .

Mais comment faire des traitement par lot comme tu fais sur les collision, sur plusieurs données d'une structure, et interagir ensuite sans casser ta boucle ?? .

TOUKO a écrit:Bah non, les boucles c'est lent, moins tu en fais mieux c'est .

Pour parcourir un tableau, les boucles c'est effectivement lent, mais tu peux très bien utiliser des listes chainées déjà, c'est plus direct et nettement plus rapide.De plus si tu dois changer de contexte plusieurs fois dans ta routine, c'est ta boucle qui gère toutes les tâches en une passe qui va être lente, et gérer en plusieurs passes peut être avantageux.

vingazole a écrit:Par contre je viens de relire ton code de Stef, il y a un problème non ?

Il me semble que dès que tu trouves une condition de "non-collision" tu branches au label .no_collid, où tu places 0 dans le registre d0 (la valeur de retour je pense) et tu sors de la routine (rts)   

Tu devrais plutôt boucler sur le prochain sprite plutôt que de sortir, à mon sens...

C'est corrigé, ça ajoute 10 cycles sur la terminaison du coup.

fanoplusplus64K a écrit:

TOUKO a écrit:Bah non, les boucles c'est lent, moins tu en fais mieux c'est .

Pour parcourir un tableau, les boucles c'est effectivement lent, mais tu peux très bien utiliser des listes chainées déjà, c'est plus direct et nettement plus rapide.De plus si tu dois changer de contexte plusieurs fois dans ta routine, c'est ta boucle qui gère toutes les tâches en une passe qui va être lente, et gérer en plusieurs passes peut être avantageux.

Oui, mais c'est pas gratos non plus, surtout quand tu t'amuses à couper des maillons .
Mais effectivement, c'est normalement comme ça qu'il faudrait faire .

Ce que je veux dire en global, c'est qu'une approche classique, t'évites de gèrer plusieurs liste,des tris etc ..
Tu as une seule liste / sprite ..

Et si on regarde sa routine de collision, c'est 116+(120*x)+20 cycles, c'est sans collision, là moi c'est bcp moins .

Si 10 sprites entre en collision c'est 116+120+30 à chaque fois soit 256/260 cycles/sprite, + le post/pre traitement à faire .
Sans les traitements, ça serait au pire égal à la mienne, donc au final meilleure .

Stef a écrit:

vingazole a écrit:Par contre je viens de relire ton code de Stef, il y a un problème non ?

Il me semble que dès que tu trouves une condition de "non-collision" tu branches au label .no_collid, où tu places 0 dans le registre d0 (la valeur de retour je pense) et tu sors de la routine (rts)   

Tu devrais plutôt boucler sur le prochain sprite plutôt que de sortir, à mon sens...

C'est corrigé, ça ajoute 10 cycles sur la terminaison du coup.

Je crois qu'il y a encore un problème, car en branchant directement sur "loop" tu ne fais plus le numEnemies-- ni le test sur la valeur de numEnemies.

Réellement tu adaptes toujours tes algos à la situation mais déjà dans le cas présent ce qui va couter c'est ton (120*x). Imagine un cas critique ou tu as 60 sprites à l'écran, même si j'appelle 60 fois ma méthode par frame, ca me fait 60 * (116 + 30) de pris par l'init + end soit 8760 cycles sur les 126000 cycles / frame = à peine 7% de mon temps CPU ! C'est ridicule en comparaison des 60 * 120 * x

vingazole a écrit:

Stef a écrit:

vingazole a écrit:Par contre je viens de relire ton code de Stef, il y a un problème non ?

Il me semble que dès que tu trouves une condition de "non-collision" tu branches au label .no_collid, où tu places 0 dans le registre d0 (la valeur de retour je pense) et tu sors de la routine (rts)   

Tu devrais plutôt boucler sur le prochain sprite plutôt que de sortir, à mon sens...

C'est corrigé, ça ajoute 10 cycles sur la terminaison du coup.

Je crois qu'il y a encore un problème, car en branchant directement sur "loop" tu ne fais plus le numEnemies-- ni le test sur la valeur de numEnemies.

ah oui, bon fallait bien je change juste mes tests... pff dur aujourd'hui  

stef, je comprends plus ta routine, elle sort quand ??

J'ai l'impression qu'elle va à collid qu'une fois toute la liste passée..

LOL, vingazole dégaine aussi .

Réellement tu adaptes toujours tes algos à la situation mais déjà dans le cas présent ce qui va couter c'est ton (120*x). Imagine un cas critique ou tu as 60 sprites à l'écran, même si j'appelle 60 fois ma méthode par frame, ca me fait 60 * (116 + 30) de pris par l'init + end soit 8760 cycles sur les 126000 cycles / frame = à peine 7% de mon temps CPU ! C'est ridicule en comparaison des 60 * 120 * x 

Si je me trompe pas 120 c'est en cas de non collision, donc même là je suis en dessous .

C'est bon normalement, j'ai corrigé pour de bon, par contre je passe à 134 cycles max par loop :-/
Je peux le réduire à 130 et pour l'instant j'ai pas encore trouvé mieux.

Mais dans quel cas 130 cycles ??

ok j'avais pas vu les modifs ..

bah c'est pire finalement, c'est à chaque non collision que tu sors, cas plus fréquent je pense .
Mais elle a un problème, si tu as une collision entre le sprite que tu teste ex le joueur est le sprite 3
Ca continue, mais si le sprite 4 collide pas, tu sors avec une non collision,donc collision du sprite 3 pas prise en compte .

TOUKO a écrit:stef, je comprends plus ta routine, elle sort quand ??

J'ai l'impression qu'elle va à collid qu'une fois toute la liste passée..

LOL, vingazole dégaine aussi .

Réellement tu adaptes toujours tes algos à la situation mais déjà dans le cas présent ce qui va couter c'est ton (120*x). Imagine un cas critique ou tu as 60 sprites à l'écran, même si j'appelle 60 fois ma méthode par frame, ca me fait 60 * (116 + 30) de pris par l'init + end soit 8760 cycles sur les 126000 cycles / frame = à peine 7% de mon temps CPU ! C'est ridicule en comparaison des 60 * 120 * x 

Si je me trompe pas 120 c'est en cas de non collision, donc même là je suis en dessous .

J'ai vraiment du mal à comprendre ta logique. La seule situation où tu peux être en dessus de moi c'est quand y'a un seul sprite à tester et qu'il n'y a pas de collision au premier test peut être.... autant dire que ce n'est pas interessant car c'est un cas qui ne posera pas de problème :-/  Pour moi y'a pas photo, le 68000 est plus performant quand y'en a besoin, c'est aussi simple que ça ! C'est pour ça que je pense que comparé à un 65816 à 3.58 Mhz, le 68000 est *au moins* 2x fois plus rapide dans la pratique.

stef, reprends ta routine y'a un soucis ...
Elle marche pas,elle peut sortir en ratant des collisions .

EDIT: ok c'est bon en fait ..

Par contre c'est bien ce que je disais ,CAD à chaque collision tu sors .
Donc c'est bien 116+134+20 si collision (tout dépend à quel niveau),min 54 si pas collision .

TOUKO a écrit:Oui, mais c'est pas gratos non plus, surtout quand tu t'amuses à couper des maillons .
Mais effectivement, c'est normalement comme ça qu'il faudrait faire .

Ce que je veux dire en global, c'est qu'une approche classique, t'évites de gèrer plusieurs liste,des tris etc ..
Tu as une seule liste / sprite ..

Je suis d'accord avec toi, rien n'est gratuit, on passe son temps à essayer d'en sauver lol
Je vais te citer un exemple très simple où une approche par liste peut être intéressante.Imaginons un shmup , tu as tes enemis et les tirs du joueur qui peuvent être de plusieurs types à la fois (r-rtype par ex : arme primaire, beam, secondaire, missiles).N'est t'il pas plus intéressant de calculer les combinaisons supplémentaires des boxes (x+l,y+h) et de les stocker dans la même structure plutôt que de traiter la collision avec les armes dans la routine de gestion des enemis ? ça peut être un cas où c'est intéressant à mon sens.

exact rien n'est gratuit lol ..

N'est t'il pas plus intéressant de calculer les combinaisons supplémentaires des boxes (x+l,y+h) et de les stocker dans la même structure plutôt que de traiter la collision avec les armes dans la routine de gestion des enemis ? ça peut être un cas où c'est intéressant à mon sens.

Bah oui c'est pas con ça, effectivement dans mon cas et surement celui de vingazole, ça réduit pas mal les cycles  ..   
Pas besoin de refaire à chaque fois les calculs ..

TOUKO a écrit:Par contre c'est bien ce que je disais ,CAD à chaque collision tu sors .
Donc c'est bien 116+134+20 si collision,min 54 si pas collision .

C'est 116+20+134 si collision au premier sprite, sinon c'est 116+20+(~110*2) au 2eme sprite, sinon 116+20+(~95*3) au 3eme et ainsi de suite... Plus tu vas avoir de sprites à tester, plus le 68000 serait avantageux. Et comme c'est toujours dans les cas ou tu as beaucoup de sprites à tester que tu veux etre le plus rapide, l'architecture du 68000 est clairement avantageuse.

C'est 116+20+134 si collision au premier sprite, sinon c'est 116+20+(~110*2) au 2eme sprite,

Oui j'ai corrigé .

Un premier jet sur Z80 avec x en 16bits et y en 8bits, 317 cycles actuellement (la version 8/8 fait 122 cycles   ) mais j'espère l'optimiser un peu (enfin 60 cycles à gagner ça me semble beaucoup)

Code:


   ;(DE) = xe(16),le(16),ye(8),he(8) enemy
   ;(HL) = xp(16),lp(16),yp(8),hp(8) player
   
   ;xp+lp<xe ?
   
   ld C,(HL)                     ;7 C=xp low
   inc L                        ;4 HL pointe sur xp hi
   ld B,(HL)                     ;7 B=xp hi
   inc L                        ;4 HL pointe sur lp low
   ld A,(HL)                     ;7 A=lp low
   inc L                        ;4 HL pointe sur lp hi
   add C                        ;4 A=lp low+xp low
   ld C,A                        ;4 sauve dans C
   ld A,(HL)                     ;7 A=lp hi
   adc B                        ;4 A=xp+lp hi + carry(xp+lp low)
   ld B,A                        ;4 sauve dans B
   
                              ;section = 56
   
   dec L                        ;4 HL pointe sur lp low
   dec L                        ;4 HL pointe sur xp hi
   dec L                        ;4 HL pointe sur xp low
   
   ex DE,HL                     ;4 HL pointe sur xe low
   
   ld A,C                        ;4 A=xp low+lp low
   sub (HL)                     ;7 A=(xp low+lp low)-xe low
   inc L                        ;4 HL pointe sur xe hi , carry non affecté
   ld A,B                        ;4 A=lp hi+xp hi
   sub (HL)                     ;7 hi(xp+lp)-carry-hi(xe)
   jr c,.no_col                  ;11/16 si plus petit , pas de collision
   
                              ;section = 53

   ;xe+le<xp ?
   
   dec L                        ;4 HL pointe sur xe low
   
   ld C,(HL)                     ;7 C=xe low
   inc L                        ;4 HL pointe sur xe hi
   ld B,(HL)                     ;7 B=xe hi
   inc L                        ;4 HL pointe sur le low
   ld A,(HL)                     ;7 A=le low
   inc L                        ;4 HL pointe sur le hi
   add C                        ;4 A=le low+xe low
   ld C,A                        ;4 sauve dans C
   ld A,(HL)                     ;7 A=le hi
   adc B                        ;4 A=xe+le hi + carry(xp+lp low)
   ld B,A                        ;4 sauve dans B
   
                              ;section = 56
   
   ex DE,HL                     ;4
   
   ld A,C                        ;4 A=xe low+le low
   sub (HL)                     ;7 A=(xe low+le low)-xp low
   inc L                        ;4 HL pointe sur xp hi , carry non affecté
   ld A,B                        ;4 A=le hi+xe hi
   sub (HL)                     ;7 hi(xe+le)-carry-hi(xp)
   jr c,.no_col                  ;11/16 si plus petit , pas de collision
   
                              ;section = 41

   ;rappel
   ;HL pointe xp hi
   ;DE pointe sur le hi
   
   inc L                        ;4 HL pointe sur lp low
   inc L                        ;4 HL pointe sur lp hi
   inc L                        ;4 HL pointe sur yp
   
   inc E                        ;4 DE pointe sur ye
   
   ;yp+hp<ye ?
   
   ld A,(DE)                     ;7 A=ye
   ld B,E                        ;4 B=ye
   ld A,(HL)                     ;7 A=yp
   inc L                        ;4 HL pointe sur lp
   add (HL)                     ;7 A=yp+hp
   cp B                        ;4 (yp+hp)<ye ?
   jr c,.no_col                  ;11/16
   
                              ;section = 60

   ;ye+he<yp ?
   
   dec L                        ;4 HL pointe sur yp
   ld B,(HL)                     ;7 B=yp
   ex DE,HL                     ;4 DE pointe sur yp , HL pointe sur ye
   ld A,(HL)                     ;7 A=ye
   inc L                        ;4 DE pointe sur he
   add (HL)                     ;7 A=ye+he
   cp B                        ;4 (ye+he)<yp ?
   jr c,.no_col
   
   scf                           ;4    carry set = collision
   ret                           ;10
   
                              ;section = 51
                              
                              
                              ;total = 317
   
.no_col
   or A                        ;4 reset carry
   ret


Bon nouvelle routine avec calcul des box déjà calc dans tableau

Code:

tab_box_joueur[8];
tab_box_sprite[8];

CollisionTest_16()  ; // VERSION 3 X=16 bit Y=8 bit                  
{
 #asm
 ; // Variables à initialiser avant l'appel de la fonction
 ; // sprite1  : sprite 1
 ; // ptr_hitbox_spr1 : tableau de collisions à 4 entrées du sprite 1
 ; // sprite2    : sprite 2
; // ptr_hitbox_spr2 : tableau de collisions à 4 entrées du sprite 2


; // TEST COLLISIONS EN X
; // debut test x'1
; // Test 1ere colone x'1 >= x2
; // Partie HIGH
5    lda _tab_box_joueur + 3
5    cmp _tab_box_sprite + 1
2/3  bne .suite_test_xprim2
; // Partie LOW
5    ldx _tab_box_joueur + 2
5    cpx _tab_box_sprite
2/3  bcc .fin_test

 .suite_test_xprim2:
; // Test 2ieme colone x'1 < x'2
; // Partie HIGH
5   cmp _tab_box_sprite + 3
2/3 bne .test_x_suite
 ; // Partie LOW
5   cpx _tab_box_sprite + 2
2/3 bcc .test_y
TOTAL 38 CYCLES

 .test_x_suite:
; // debut test x1
; // Test  x1 >= x2
; // Partie LOW
    lda _tab_box_joueur + 1
    cmp _tab_box_sprite + 1
    bne .fin_test
; // Partie HIGH
    ldx _tab_box_joueur
    cpx _tab_box_sprite
    bcc .test_y

; // Test  x1 <= x'2
; // Partie LOW
    cmp _tab_box_sprite + 3
    bne .fin_test
; // Partie HIGH
    cpx _tab_box_sprite + 2
    bcc .test_y
TOTAL 38 CYCLES
SOIT 38 * 2 = 76 CYCLES
 .fin_test:
    stz <collision ; // Annule la collision si test negatif en mettant la var collision à 0
    rts
 
; // TEST COLLISIONS EN Y
 .test_y:
 ; // idem test x
SOIT 38 * 2 = 76 CYCLES

TOTAL 76*2 = 152 CYCLES
 
.col_ok:
6   inc <collision     ; // Si collision ,alors collision <> 0
2   lda  #1                ; //si retour dans REG A
7   rts

 #endasm
}

161 CYCLES max si sortie dans registre en 16/8
165 cycles max si variables

min 25 si registre .
Mid 50 si registre

Tu veux dire avec X+L et Y+H déjà calculées dans le tableau ?

Oui,tu les calcules a chaque frame dans un tableau en ram, juste les sprites actifs .
Et comme sur 65xx l indexation est gratuite .
Comme stef fait ses listes de sprites a tester.

OK, donc tu changes la méthode pour avantager le 65xx avec des indexations gratuites...
Ce n'est pas fairplay ça !

fanoplusplus64K a écrit:Un premier jet sur Z80 avec x en 16bits et y en 8bits, 317 cycles actuellement (la version 8/8 fait 122 cycles   ) mais j'espère l'optimiser un peu (enfin 60 cycles à gagner ça me semble beaucoup)

Code:


 ;(DE) = xe(16),le(16),ye(8),he(8) enemy
 ;(HL) = xp(16),lp(16),yp(8),hp(8) player

;xp+lp<xe ?
 
ld C,(HL) ;7 C=xp low
 inc L ;4 HL pointe sur xp hi
 ld B,(HL) ;7 B=xp hi
 inc L ;4 HL pointe sur lp low
 ld A,(HL) ;7 A=lp low
 inc L ;4 HL pointe sur lp hi
 add C ;4 A=lp low+xp low
 ld C,A ;4 sauve dans C
 ld A,(HL) ;7 A=lp hi
 adc B ;4 A=xp+lp hi + carry(xp+lp low)
 ld B,A ;4 sauve dans B
 
;section = 56
 
dec L ;4 HL pointe sur lp low
 dec L ;4 HL pointe sur xp hi
 dec L ;4 HL pointe sur xp low
 
ex DE,HL ;4 HL pointe sur xe low
 
ld A,C ;4 A=xp low+lp low
 sub (HL) ;7 A=(xp low+lp low)-xe low
 inc L ;4 HL pointe sur xe hi , carry non affecté
 ld A,B ;4 A=lp hi+xp hi
 sub (HL) ;7 hi(xp+lp)-carry-hi(xe)
 jr c,.no_col ;11/16 si plus petit , pas de collision
 
;section = 53

 ;xe+le<xp ?
 
dec L ;4 HL pointe sur xe low
 
ld C,(HL) ;7 C=xe low
 inc L ;4 HL pointe sur xe hi
 ld B,(HL) ;7 B=xe hi
 inc L ;4 HL pointe sur le low
 ld A,(HL) ;7 A=le low
 inc L ;4 HL pointe sur le hi
 add C ;4 A=le low+xe low
 ld C,A ;4 sauve dans C
 ld A,(HL) ;7 A=le hi
 adc B ;4 A=xe+le hi + carry(xp+lp low)
 ld B,A ;4 sauve dans B
 
;section = 56
 
ex DE,HL ;4
 
ld A,C ;4 A=xe low+le low
 sub (HL) ;7 A=(xe low+le low)-xp low
 inc L ;4 HL pointe sur xp hi , carry non affecté
 ld A,B ;4 A=le hi+xe hi
 sub (HL) ;7 hi(xe+le)-carry-hi(xp)
 jr c,.no_col ;11/16 si plus petit , pas de collision
 
;section = 41

 ;rappel
 ;HL pointe xp hi
 ;DE pointe sur le hi
 
inc L ;4 HL pointe sur lp low
 inc L ;4 HL pointe sur lp hi
 inc L ;4 HL pointe sur yp
 
inc E ;4 DE pointe sur ye
 
;yp+hp<ye ?
 
ld A,(DE) ;7 A=ye
 ld B,E ;4 B=ye
 ld A,(HL) ;7 A=yp
 inc L ;4 HL pointe sur lp
 add (HL) ;7 A=yp+hp
 cp B ;4 (yp+hp)<ye ?
 jr c,.no_col ;11/16
 
;section = 60

 ;ye+he<yp ?
 
dec L ;4 HL pointe sur yp
 ld B,(HL) ;7 B=yp
 ex DE,HL ;4 DE pointe sur yp , HL pointe sur ye
 ld A,(HL) ;7 A=ye
 inc L ;4 DE pointe sur he
 add (HL) ;7 A=ye+he
 cp B ;4 (ye+he)<yp ?
 jr c,.no_col
 
scf ;4    carry set = collision
 ret ;10
 
;section = 51
 

;total = 317
 
.no_col
 or A ;4 reset carry
 ret


Waou, ça c'est joli !

Ca impose une contrainte sur la position des valeurs enemy et player, si je comprends bien, pour ne pas passer de HL=xxFF à HL=xx00 en incrémentant seulement L (sim. avec DE) ?

La seule "optimisation" que je vois c'est de tester d'abord en Y (donc de changer l'ordre des valeurs pointées par HL et DE) vu que les comparaisons 8 bits sont plus rapides et que l'on sort dès qu'on est sûr qu'il n'y a pas collision. Bien sûr ça ne changerait pas le nombre de cycles dans le pire des cas (collision) !

Edit: si on inverse la logique de sortie (CF=0 <=> collision), on peut remplacer les quatre "jr c,.no_col" par des "ret c" et enlever le "scf", ça doit faire gagner quelques cycles. Du coup on peut supprimer le label ".no_col" et son "contenu".

Edit2: c'est bizarre, tu donnes 11/16 cycles pour le "jr c," alors que ma doc Zilog indique 7/12  

vingazole a écrit:
Waou, ça c'est joli !

Ca impose une contrainte sur la position des valeurs enemy et player, si je comprends bien, pour ne pas passer de HL=xxFF à HL=xx00 en incrémentant seulement L (sim. avec DE) ?

La seule "optimisation" que je vois c'est de tester d'abord en Y (donc de changer l'ordre des valeurs pointées par HL et DE) vu que les comparaisons 8 bits sont plus rapides et que l'on sort dès qu'on est sûr qu'il n'y a pas collision. Bien sûr ça ne changerait pas le nombre de cycles dans le pire des cas (collision) !

Oui , il faut que les eléments du tableau soient dans la même page donc alignés sur 6 octets ce qui n'est pas une grosse contrainte.

Oui , j'avais bien pensé effectivement à des optimisation du genre de celle qui tu mentionnes mais je ne voulais pas que le code soit trop confus et tenter d'avoir la meilleure performance dans le pire des cas.On peut gagner un petit peu (24cycles) en inversant la carry (collision=no carry) en utilisant ret c à la place du jr c, et en resetant la carry en cas de succès.Il est possible aussi de gagner un peu de cycles en alignant les coordonnées du joueur sur un page de 256 octets, ce qui est peu gênant car elle est fixe.

D'ailleurs il y avait une petite coquille dans mon code , car j'ai utilise sub (HL) à certains endroits au lieu de sbc (HL) , ça ne change pas le nombre de cycles mais c'est pas bon   

Voilà une version corrigée à 299 cycles :

Code:

   ;(DE) = xe(16),le(16),ye(8),he(8) enemy
   ;(HL) = xp(16),lp(16),yp(8),hp(8) player
   
   ;xp+lp<xe ?
   
   ld C,(HL)                     ;7 C=xp low
   inc L                        ;4 HL pointe sur xp hi
   ld B,(HL)                     ;7 B=xp hi
   inc L                        ;4 HL pointe sur lp low
   ld A,(HL)                     ;7 A=lp low
   inc L                        ;4 HL pointe sur lp hi
   add C                        ;4 A=lp low+xp low
   ld C,A                        ;4 sauve dans C
   ld A,(HL)                     ;7 A=lp hi
   adc B                        ;4 A=xp+lp hi + carry(xp+lp low)
   ld B,A                        ;4 sauve dans B
   
                              ;section = 56
   
   dec L                        ;4 HL pointe sur lp low
   dec L                        ;4 HL pointe sur xp hi
   dec L                        ;4 HL pointe sur xp low
   
   ex DE,HL                     ;4 HL pointe sur xe low
   
   ld A,C                        ;4 A=xp low+lp low
   sub (HL)                     ;7 A=(xp low+lp low)-xe low
   inc L                        ;4 HL pointe sur xe hi , carry non affecté
   ld A,B                        ;4 A=lp hi+xp hi
   sbc (HL)                     ;7 hi(xp+lp)-carry-hi(xe)
   ret c                        ;5/11 si plus petit , pas de collision
   
                              ;section = 47

   ;xe+le<xp ?
   
   dec L                        ;4 HL pointe sur xe low
   
   ld C,(HL)                     ;7 C=xe low
   inc L                        ;4 HL pointe sur xe hi
   ld B,(HL)                     ;7 B=xe hi
   inc L                        ;4 HL pointe sur le low
   ld A,(HL)                     ;7 A=le low
   inc L                        ;4 HL pointe sur le hi
   add C                        ;4 A=le low+xe low
   ld C,A                        ;4 sauve dans C
   ld A,(HL)                     ;7 A=le hi
   adc B                        ;4 A=xe+le hi + carry(xp+lp low)
   ld B,A                        ;4 sauve dans B
   
                              ;section = 56
   
   ex DE,HL                     ;4
   
   ld A,C                        ;4 A=xe low+le low
   sub (HL)                     ;7 A=(xe low+le low)-xp low
   inc L                        ;4 HL pointe sur xp hi , carry non affecté
   ld A,B                        ;4 A=le hi+xe hi
   sbc (HL)                     ;7 hi(xe+le)-carry-hi(xp)
   ret c                        ;5/11 si plus petit , pas de collision
   
                              ;section = 35

   ;rappel
   ;HL pointe xp hi
   ;DE pointe sur le hi
   
   inc L                        ;4 HL pointe sur lp low
   inc L                        ;4 HL pointe sur lp hi
   inc L                        ;4 HL pointe sur yp
   
   inc E                        ;4 DE pointe sur ye
   
   ;yp+hp<ye ?
   
   ld A,(DE)                     ;7 A=ye
   ld B,E                        ;4 B=ye
   ld A,(HL)                     ;7 A=yp
   inc L                        ;4 HL pointe sur lp
   add (HL)                     ;7 A=yp+hp
   cp B                        ;4 (yp+hp)<ye ?
   ret c                        ;5/11 si plus petit , pas de collision
   
                              ;section = 54

   ;ye+he<yp ?
   
   dec L                        ;4 HL pointe sur yp
   ld B,(HL)                     ;7 B=yp
   ex DE,HL                     ;4 DE pointe sur yp , HL pointe sur ye
   ld A,(HL)                     ;7 A=ye
   inc L                        ;4 DE pointe sur he
   add (HL)                     ;7 A=ye+he
   cp B                        ;4 (ye+he)<yp ?
   ret c                        ;5/11 si plus petit , pas de collision
   
   or                           ;4    carry reset = collision
   ret                           ;10
   
                              ;section = 51
                              
                              
                              ;total = 299
   
.no_col
   or A                        ;4 reset carry
   ret                           ;10


vingazole a écrit:
Edit2: c'est bizarre, tu donnes 11/16 cycles pour le "jr c," alors que ma doc Zilog indique 7/12  

C'est moi qui ai encore bu , je sais pas où je suis allé chercher ça   

En parlant de ça , la version avec les additions précalculées, 176 cycles

Code:

   ;in :
   ;(HL) = xe(16),xe+le(16),ye(8),ye+he(8) enemy (6 aligned)
   ;(DE) = xp(16),xp+lp(16),yp(8),ye+hp(8) player (256 aligned)
   
   ;out :
   ;carry set if no collision
   ;carry reset if collision

   ;xp+lp<xe ?
   
   ld E,2         ;7 DE pointe sur xp+lp low
   
   ld A,(DE)      ;7 A = xp+lp low
   sub (HL)      ;7 xp+lp low - xe low
   inc E         ;4 DE pointe sur xp+lp hi
   inc L         ;4 HL pointe sur xe hi
   ld A,(DE)      ;7 A = xp+lp hi
   sbc (HL)      ;7 A = xp+lp hi - xe hi - carry
   ret c         ;5/11 pas de collision si xp+lp<xe
   
               ;section = 41
   
   ;xe+le<xp ?
   
   ld E,0         ;7 DE pointe sur xp low
   
   inc L         ;4 HL pointe sur xe+le low
   
   ex DE,HL      ;4 HL pointe sur xp low , DE pointe sur xe+le low
   ld A,(DE)      ;7 A=xe+le low
   sub (HL)      ;7 xe+le low - xp low
   inc E         ;4 DE pointe sur xe+le hi
   inc L         ;4 HL pointe sur xp hi
   ld A,(DE)      ;7 A=xe+le hi
   sbc (HL)      ;7 A=xe+le hi - xp hi - carry
   ret c         ;5/11 pas de collision si xe+le<xp
   
               ;section = 56 ;53
   
   ;yp+hp<ye ?

   
   ld L,5         ;7 HL pointe sur yp+hp   
   inc E         ;4 DE pointe sur ye
   
   ld A,(DE)      ;7 A=ye
   ld C,A         ;4 C=ye
   ld A,(HL)      ;7 A=yp+hp
   sub C         ;4 A=(yp+hp)-ye
   ret c         ;5/11
   
               ;section = 38
   
   ;ye+he<yp ?
   
   dec L         ;4 HL pointe sur yp
   inc E         ;4 DE pointe sur ye+he
   ld A,(DE)      ;7 A = ye+he
   sub (HL)      ;7 A = (ye+he)-yp
   ret c         ;5/11 pas de collision si xe+le<xp
   
   or A         ;4 reset carry
   ret            ;10
   
               ;section = 41
               
               ;total =176