Re: Meilleurs algo d'un test par bouding box

par Invité Lun 3 Fév 2014 - 16:18

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.

par Stef Lun 3 Fév 2014 - 16:19

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 vingazole Lun 3 Fév 2014 - 16:20

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

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

par Invité Lun 3 Fév 2014 - 16:21

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 .

par Stef Lun 3 Fév 2014 - 16:21

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

par fanoplusplus64K Lun 3 Fév 2014 - 16:24

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

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.

par Invité Lun 3 Fév 2014 - 16:25

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

par fanoplusplus64K Lun 3 Fév 2014 - 16:28

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.

par Stef Lun 3 Fév 2014 - 16:28

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.

par Invité Lun 3 Fév 2014 - 16:32

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 .

par vingazole Lun 3 Fév 2014 - 16:43

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.

par Stef Lun 3 Fév 2014 - 16:45

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 Wink

par Stef Lun 3 Fév 2014 - 16:46

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 MDR

par Invité Lun 3 Fév 2014 - 16:46

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 .

par Stef Lun 3 Fév 2014 - 16:56

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.

par Invité Lun 3 Fév 2014 - 16:56

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 .

par Stef Lun 3 Fév 2014 - 17:03

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.

par Invité Lun 3 Fév 2014 - 17:06

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 .

par fanoplusplus64K Lun 3 Fév 2014 - 17:32

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.

par Invité Lun 3 Fév 2014 - 17:57

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 .. scratch

Pas besoin de refaire à chaque fois les calculs ..

par Stef Lun 3 Fév 2014 - 18:28

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.

par Invité Lun 3 Fév 2014 - 18:33

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

Oui j'ai corrigé .

par fanoplusplus64K Lun 3 Fév 2014 - 19:16

Un premier jet sur Z80 avec x en 16bits et y en 8bits, 317 cycles actuellement (la version 8/8 fait 122 cycles Sad

) 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

par Invité Lun 3 Fév 2014 - 19:44

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

par fanoplusplus64K Lun 3 Fév 2014 - 19:46

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

par Invité Lun 3 Fév 2014 - 19:56

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.

par **TotOOntHeMooN** Lun 3 Fév 2014 - 20:29

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

par vingazole Lun 3 Fév 2014 - 20:29

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 scratch

par fanoplusplus64K Lun 3 Fév 2014 - 21:04

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 MDR

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

par fanoplusplus64K Lun 3 Fév 2014 - 21:06

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 What the fuck ?!?

par fanoplusplus64K Lun 3 Fév 2014 - 21:11

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