Re: MEGADRIVE vs SUPER NINTENDO : Fight !

par Invité Sam 1 Fév 2014 - 23:32

C'est tout... tu te braques tellement que tu ne prends pas la peine de lire correctement :p

Paille, poutre, tout ça stef Wink

et on compte tout, init des registres comprise ...

par Stef Sam 1 Fév 2014 - 23:46

pour moi l'important c'est de compter ce que ça coute sur un paquet de tests de collision, genre 50 (ou plus), histoire que ça soit représentatif de conditions réelles. Toi t'es un spécialiste pour tester un cas isolé dont on se fout complètement :p

par Invité Dim 2 Fév 2014 - 0:05

Ok ca commence les excuses !!!
c'est sur en conditions réelles tu vas pouvoir garder les données tout les temps dans les registres ..
Je savais que tu allais me sortir un truc pareil .
Justement, je parlais d'un cas concret en situ, dans un jeu, et pas ta magies d'avoir des registres déjà chargés, on ne sait comment ..

en situ tu enchaines pas tout les tests de collisions à la fille, en fonction de chaque test tu vas faire autre chose ..
Bien sur dans un jeu tu en auras bien plus que 50, mais pas à la suite .

enfin bref fais comme tu veux .

Tu as déjà des routines de tests, tu en es à combien de cycles ??

par **TotOOntHeMooN** Dim 2 Fév 2014 - 0:15

TOUKO a écrit:y'a aussi totoonthemoon présent ici, qui à retouché les grafs .

Retouché... C'est mignon. Sad

par Invité Dim 2 Fév 2014 - 0:21

dsl, j'ai pas employé le bon terme, mais comme dans mon idée la partie graphique de base existait déjà, j'ai employé ce mot . Embarassed

Refait aurait été le terme exact .

par Stef Dim 2 Fév 2014 - 1:41

TOUKO a écrit:Ok ca commence les excuses !!!
c'est sur en conditions réelles tu vas pouvoir garder les données tout les temps dans les registres ..
Je savais que tu allais me sortir un truc pareil .
Justement, je parlais d'un cas concret en situ, dans un jeu, et pas ta magies d'avoir des registres déjà chargés, on ne sait comment ..

en situ tu enchaines pas tout les tests de collisions à la fille, en fonction de chaque test tu vas faire autre chose ..
Bien sur dans un jeu tu en auras bien plus que 50, mais pas à la suite .

enfin bref fais comme tu veux .

Tu as déjà des routines de tests, tu en es à combien de cycles ??

O_o ???
Mais je compterai tout, le temps d'init etc... mais ce que je veux, c'est compter le temps total pour computer N collisions et pas 1 collision, on est bien d'accord ?
Tu optimises ton code comme tu veux, il est évident qu'on ne code pas de la même manière avec un 6502 et un 68000 (heureusement)... l'important au bout du compte, c'est d'avoir fait le calcul de tes X collisions le plus rapidement possible, on est bien d'accord.
Et non je n'ai psa de routine ou quoique ce soit de prêt, je t'ai dis, tu me donnes un algo optimisé pour ton CPU et je me débrouille pour refaire le même sur 68000 et on compare à la fin. Plus tot tu disais avoir un algo rapide pour faire un collision rapide de type bouding box, on peut partir de ça si tu veux, mais je veux le code (pour voir ce qu'il fait exactement) et le nombre de cycle. Le but pour moi c'est de te démontrer qu'on ne peut clairement pas comparer des CPU uniquement sur leur IPS (ou MIPS) Wink

par Invité Dim 2 Fév 2014 - 8:59

Ok je vais faire un algo le plus optimal possible ..
Rien ne t'empêche d'en sortir un que tu as déjà ..

De toutes façons on comptera qu'au résultat final CAD au max de l'optimisation possible de chacun ..
Donc plusieurs versions sont autorisées ..

Mais je compterai tout, le temps d'init etc... mais ce que je veux, c'est compter le temps total pour computer N collisions et pas 1 collision, on est bien d'accord ?

Comment veux tu faire ça ??, vu qu'après un test de collision, tu passes pas à un autre, tu traites le résultat pour le(s) sprites en cours, joue un (des) sons, avant de passer au suivant ..

ne cherches pas à extrapoler des résultats sans tenir compte du contexte .
Style en te mettant dans le cas le plus favorable, et en multipliant x50 le tout, alors que ça correspond en rien à un cas réel .

par vingazole Dim 2 Fév 2014 - 10:12

Non mais arrêtez de pinailler sans fin et faites-nous déjà un (seul) test de collision, on verra peut-être plus tard pour N collisions Rolling Eyes

S'il vous plait

par Invité Dim 2 Fév 2014 - 10:33

ok test simple bounding box 16 bit non optimisé 365 cycles si collision .
elle est entièrement fonctionnelle, testée et tout sans bug .
ca fonctionne comme ça .
on prend les coord X/Y du spr1 on ajoute la box, on fait pareil pour le SPR2 et on compare leur X1X2 et Y1Y2 respectifs .
Les données de la box sont dans un tableau,et sont donc variables .

Code:: ; // 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 CollisionTest_16() { #asm ; // TEST COLLISIONS EN X ; // Calcul x'1 5 lda _pos_x1 ; // Ajout de val_x1 + 1 à x1 2 clc 9 adc [ ptr_hitbox_spr1 ].1 4 sta <calc_pos 5 lda _pos_x1 + 1 2 adc #0 4 sta <calc_pos + 1 31 cycles ; // Calcul x2 lda _pos_x2 ; // Ajout de val_x2 à x2 clc adc [ ptr_hitbox_spr2 ] sta <calc_pos + 2 lda _pos_x2 + 1 adc #0 sta <calc_pos + 3 29 cycles ; // debut test x'1 4 lda <calc_pos + 3 4 cmp <calc_pos + 1 2/3 bne .suite_test1 4 lda <calc_pos + 2 4 cmp <calc_pos 2/3 bcc .fin_test 20 cycles .suite_test1: TOTAL 51 cycles ; // Calcul x'2 lda _pos_x2 ; // Ajout de val_x2 + 1 à x2 clc adc [ ptr_hitbox_spr2 ].1 sta <calc_pos + 4 lda _pos_x2 + 1 adc #0 sta <calc_pos + 5 31 cycles cmpw <calc_pos + 4 , <calc_pos ; // Test 2ieme colone x'1 < x'2 bcc .test_y 20 cycles .test_x_suite: ; // Calcul x1 lda _pos_x1 ; // Ajout de val_x1 à x1 clc adc [ ptr_hitbox_spr1 ] sta <calc_pos lda _pos_x1 + 1 adc #0 sta <calc_pos + 1 29 cycles TOTAL 80 + 51 = 131 ; // debut test x1 4 lda <calc_pos + 1 4 and <calc_pos + 3 ; // Test 1ere colone x1 >= x2 4 eor <calc_pos + 5 2/3 bne .fin_test 14/15 cycles 4 lda <calc_pos 4 cmp <calc_pos + 2 ; // Test 2ieme colone x1 < x'2 2/3 bcc .fin_test 4 cmp <calc_pos + 4 2/3 bcc .test_y 16/18 cycles .fin_test: stz <collision ; // Annule la collision si test negatif en mettant la var collision à 0 rts TOTAL 133 cycles ; // TEST COLLISIONS EN Y .test_y: lda _pos_y1 ; // Ajout de val_y1 à y1 clc adc [ ptr_hitbox_spr1 ].2 sta <calc_pos lda _pos_y1 + 1 adc #0 sta <calc_pos + 1 31 ; // Calcul y'2 lda _pos_y2 ; // Ajout de val_y2 + 1 à y2 clc adc [ ptr_hitbox_spr2 ].3 sta <calc_pos + 2 lda _pos_y2 + 1 adc #0 sta <calc_pos + 3 31 cmpw <calc_pos + 2 , <calc_pos bcs .fin_test 20 TOTAL 215 cycles ; // Calcul y2 lda _pos_y2 ; // Ajout de val_y2 à y2 clc adc [ ptr_hitbox_spr2 ].2 sta <calc_pos + 4 tax lda _pos_y2 + 1 adc #0 sta <calc_pos + 5 cmpw <calc_pos + 4 , <calc_pos ; // Test 1ere ligne y1 >= y2 bcs .col_ok 51 .test_y_suite: ; // Calcul y'1 lda _pos_y1 ; // Ajout de val_y1 + 1 à y1 clc adc [ ptr_hitbox_spr1 ].3 sta <calc_pos lda _pos_y1 + 1 adc #0 sta <calc_pos + 1 31 lda <calc_pos + 1 and <calc_pos + 3 eor <calc_pos + 5 bne .fin_test lda <calc_pos cmp <calc_pos + 2 bcs .fin_test cmp <calc_pos + 4 bcc .fin_test 31 .col_ok: TOTAL 328 cycles inc <collision ; // Si collision ,alors collision <> 0 rts #endasm }

EDIT : j'ai corrigé le nb de cycles, j'avais oublié de compter un bloc hier soir ..

par vingazole Dim 2 Fév 2014 - 10:55

Ah ben voilà du concret, merci TOUKO pour ton exemple de bounding box bounce

par Invité Dim 2 Fév 2014 - 11:03

LOL, merde corrigé Mr. Green

tu nous ferrais pas le même en Z80 ???

par ace76 Dim 2 Fév 2014 - 11:10

Hé les mecs ,vous dormez la nuit?? Shocked

par vingazole Dim 2 Fév 2014 - 11:20

TOUKO a écrit:tu nous ferrais pas le même en Z80 ???

Je veux bien mais alors décris-moi précisément tes variables (en particulier leur type) et essaie de traduire ton code en pseudo-code, parce que j'ai du mal à trouver de la doc sur l'assembleur 6280 et donc à suivre ce que tu fais...
help

Par contre on n'est peut-être pas tout à fait dans le bon topic, là...

par Invité Dim 2 Fév 2014 - 11:33

Ok, je te ferrais ça, là j'ai pas le temps de rentrer dans les détails, je vais partir .
Ca serrait sympa de voir ce que ça donne sur 3 cpu différents .

Hé les mecs ,vous dormez la nuit??

EDIT: j'ai vite rajouté un supplément d'infos, je t'en donnerai plus plus tard si tu as besoin .

par vingazole Dim 2 Fév 2014 - 11:49

En effet, ce serait sympa de comparer sur différents cpu !

D'ailleurs en faisant appel à ma mémoire (c'est pas gagné^^) je pourrais écrire une version 8086 study

par Stef Dim 2 Fév 2014 - 11:59

Ok je vais faire un algo le plus optimal possible ..
Rien ne t'empêche d'en sortir un que tu as déjà ..

Je n'ai rien, j'en ai pas eu encore besoin (j'ai du code tout pourri en C mais heu... ça va pas le faire).

De toutes façons on comptera qu'au résultat final CAD au max de l'optimisation possible de chacun ..
Donc plusieurs versions sont autorisées ..

Bien sur, mais il faut que ça reste un test plus ou moins générique, pas d'aprioris foireux Wink

Comment veux tu faire ça ??, vu qu'après un test de collision, tu passes pas à un autre, tu traites le résultat pour le(s) sprites en cours, joue un (des) sons, avant de passer au suivant

Heu pas forcément non, enfin tu vas au moins stocker le résultat mais rien ne t'empêche de traiter toutes les collisions pour chaque objets les uns après les autres.
Moi je vois ça comme ça, en gros t'as une box1, et tu testes la collision avec une liste de box.
Le prototype en C ressemblerait à ça en quelque sorte :

Code:: int testCollid(Box object, Box boxes[]);

Le retour de la méthode te donnerait le nombre de hit (important si ton vaisseau résiste à plusieurs hit). On pourrait aussi se dire que ça retourne 1 si collision et 0 sinon, mais ça répond à moins de cas. C'est toi qui voit, moi je m'en fous :p

edit:
Ah mince j'aurais du lire les autres posts avant de répondre, j'avais pas vu que tu avais proposé un prototype. Je vais m'y conformer alors.

par Stef Dim 2 Fév 2014 - 12:02

Heu effectivement on pourrait peut être faire ça dans un topic dédié ? ou ça rentre dans le sujet ?

Ah mais c'est illisible le code ASM 6280, j'y comprends rien X'D
Non plus sérieusement tu pourrais détailler un peu tes structures ou donner un code C équivalent ? parce-que là parfois j'ai des doutes, genre cette partie :

Code:: 4 lda <calc_pos + 1 4 and <calc_pos + 3 ; // Test 1ere colone x1 >= x2 4 eor <calc_pos + 5 2/3 bne .fin_test

Je ne comprends pas comment tu fais ton test de x1 >= x2 avec un lda / and / eor mais bon j'avoue ne pas avoir lu encore tout l'algo.

par Stef Dim 2 Fév 2014 - 13:19

Bon j'ai essayé de reprendre ton algo, mais y'a rien à faire, y'a des parties que je ne comprends pas... ton code me semble bien plus compliqué et sans raison, et je compte plus que les 328 cycles que tu indiques (plutot 400) mais bon...

Voici le code 68000 que je viens d'écrire pour faire le même test de collision que toi, honnêtement je trouve mon code bien plus claire et plus simple Razz

Code:: 12 lea spr1, a0 12 lea hitbox1, a1 12 lea spr2, a2 12 lea hitbox2, a3 48 // TEST on X coordinates 12 move.w 0(a0), d0 ; d0 = spr1.x 12 add.w 2(a1), d0 ; d0 = spr1.x + box1.xmax = spr1.xmax 12 move.w 0(a2), d1 ; d0 = spr2.x 12 add.w 0(a3), d1 ; d0 = spr2.x + box2.xmin = spr2.xmin 48 4 cmp.w d0,d1 ; if (spr1.xmax < spr2.xmin) 10 bgt .no_collid ; no collision 14 12 move.w 0(a0), d0 ; d0 = spr1.x 12 add.w 0(a1), d0 ; d0 = spr1.x + box1.xmin = spr1.xmin 12 move.w 0(a2), d1 ; d0 = spr2.x 12 add.w 2(a3), d1 ; d0 = spr2.x + box2.xmax = spr2.xmax 48 4 cmp.w d0,d1 ; if (spr1.xmin > spr2.xmax) 10 blt .no_collid ; no collision 14 // TEST on Y coordinates 12 move.w 2(a0), d0 ; d0 = spr1.y 12 add.w 6(a1), d0 ; d0 = spr1.y + box1.ymax = spr1.ymax 12 move.w 2(a2), d1 ; d0 = spr2.y 12 add.w 4(a3), d1 ; d0 = spr2.y + box2.ymin = spr2.ymin 48 4 cmp.w d0,d1 ; if (spr1.ymax < spr2.ymin) 10 bgt .no_collid ; no collision 14 12 move.w 2(a0), d0 ; d0 = spr1.y 12 add.w 4(a1), d0 ; d0 = spr1.y + box1.ymin = spr1.ymin 12 move.w 2(a2), d1 ; d0 = spr2.y 12 add.w 6(a3), d1 ; d0 = spr2.y + box2.ymax = spr2.ymax 48 4 cmp.w d0,d1 ; if (spr1.ymin > spr2.ymax) 10 blt .no_collid ; no collision 14 .collid 4 move #1,d0 ; return 1 16 rts .no_collid 4 move #0,d0 ; return 0 16 rts

Si je ne me suis pas planté dans mes calculs, dans le pire des cas ma routine prend 316 cycles.
Et j'ai vraiment fait le code "naive way", c'est pas du tout optimisé.

par vingazole Dim 2 Fév 2014 - 17:23

Je suis parti du code de Stef, avec ses définitions de variables (sauf erreur) :

Code:: struct sprite { int x,y; } spr1,spr2; struct hitbox { int xmin, xmax, ymin, ymax; } hitbox1,hitbox2;

J'ai essayé de coller au maximum à son algorithme :

Code:: // TEST on X coordinates ld hl,(spr1) // hl = spr1.x ex de,hl // swap de,hl ld hl,(2+hitbox1) // hl = hitbox1.xmax add hl,de // hl = spr1.x + hitbox1.xmax ld b,h ld c,l // bc = hl ld hl,(spr2) // hl = spr2.x ex de,hl // swap de,hl ld hl,(hitbox2) // hl = hitbox2.xmin add hl,de // hl = spr2.x + hitbox2.xmin ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr nc,no_collid // if (spr1.x + hitbox1.xmax <= spr2.x + hitbox2.xmin) no_collid // ------------------ ld hl,(spr1) // hl = spr1.x ex de,hl // swap de,hl ld hl,(hitbox1) // hl = hitbox1.xmin add hl,de // hl = spr1.x + hitbox1.xmin ld b,h ld c,l // bc = hl ld hl,(spr2) // hl = spr2.x ex de,hl // swap de,hl ld hl,(2+hitbox2) // hl = hitbox2.xmax add hl,de // hl = spr2.x + hitbox2.xmax ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr c,no_collid // if (spr1.x + hitbox1.xmin > spr2.x + hitbox2.xmax) no_collid // TEST on Y coordinates ld hl,(2+spr1) // hl = spr1.y ex de,hl // swap de,hl ld hl,(6+hitbox1) // hl = hitbox1.ymax add hl,de // hl = spr1.y + hitbox1.ymax ld b,h ld c,l // bc = hl ld hl,(2+spr2) // hl = spr2.y ex de,hl // swap de,hl ld hl,(4+hitbox2) // hl = hitbox2.ymin add hl,de // hl = spr2.y + hitbox2.ymin ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr nc,no_collid // if (spr1.y + hitbox1.ymax <= spr2.y + hitbox2.ymin) no_collid // ------------------ ld hl,(2+spr1) // hl = spr1.y ex de,hl // swap de,hl ld hl,(4+hitbox1) // hl = hitbox1.ymin add hl,de // hl = spr1.y + hitbox1.ymin ld b,h ld c,l // bc = hl ld hl,(2+spr2) // hl = spr2.y ex de,hl // swap de,hl ld hl,(6+hitbox2) // hl = hitbox2.ymax add hl,de // hl = spr2.y + hitbox2.ymax ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr c,no_collid // if (spr1.y + hitbox1.ymin > spr2.y + hitbox2.ymax) no_collid .collid scf // cf = 1 jr end .no_collid or a // cf = 0 .end

Total : 560 cycles en cas de collision.

Ca pourrait sûrement être optimisé, mais à titre de comparaison il faut savoir que les opérations les plus rapides (par exemple un NOP) prennent 4 cycles sur un z80
Boulet

par Invité Dim 2 Fév 2014 - 21:05

Nan mais je proposerai un algo normal, là j'ai juste posté un truc générique et en asm, donc comme le souligne stef pas exploitable ..

@vingazole : merci pour ton premier jet ..
Mais si tu es parti de mon code, c'est peut être normal ..
Eh on va quand même pas se laisser mettre à l'amande par un 68000 quand même Wink

@stef: merci aussi de jouer le jeu Wink

.
pareil, si tu es parti de mon code, c'est peut être normal aussi ..
Mais je me doutait que le code 68k serait plus simple et plus lisible .
Toute ma tabulation est partie en couille quand j'ai fait le copier, de plus j'ai aussi mis les cycles à coté ..
J'essayerai de faire un truc plus user friendly la prochaine foi .

Vous m'avez donné envie, non pas de comparer nos bites mais vraiment de faire un truc sympa en comparant nos approches, et nos astuces .

Surtout que ce type de détection est générique, et pourrait servir à tout le monde .

Je ne comprends pas comment tu fais ton test de x1 >= x2 avec un lda / and / eor mais bon j'avoue ne pas avoir lu encore tout l'algo.

Astuce de sioux, mais je décrirais ce que je fais sans soucis . Wink

par Stef Dim 2 Fév 2014 - 22:02

vingazole a écrit:Je suis parti du code de Stef, avec ses définitions de variables (sauf erreur) :
Code:
struct sprite { int x,y; } spr1,spr2; struct hitbox { int xmin, xmax, ymin, ymax; } hitbox1,hitbox2;

J'ai essayé de coller au maximum à son algorithme :
Code:
// TEST on X coordinates ld hl,(spr1) // hl = spr1.x ex de,hl // swap de,hl ld hl,(2+hitbox1) // hl = hitbox1.xmax add hl,de // hl = spr1.x + hitbox1.xmax ld b,h ld c,l // bc = hl ld hl,(spr2) // hl = spr2.x ex de,hl // swap de,hl ld hl,(hitbox2) // hl = hitbox2.xmin add hl,de // hl = spr2.x + hitbox2.xmin ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr nc,no_collid // if (spr1.x + hitbox1.xmax <= spr2.x + hitbox2.xmin) no_collid // ------------------ ld hl,(spr1) // hl = spr1.x ex de,hl // swap de,hl ld hl,(hitbox1) // hl = hitbox1.xmin add hl,de // hl = spr1.x + hitbox1.xmin ld b,h ld c,l // bc = hl ld hl,(spr2) // hl = spr2.x ex de,hl // swap de,hl ld hl,(2+hitbox2) // hl = hitbox2.xmax add hl,de // hl = spr2.x + hitbox2.xmax ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr c,no_collid // if (spr1.x + hitbox1.xmin > spr2.x + hitbox2.xmax) no_collid // TEST on Y coordinates ld hl,(2+spr1) // hl = spr1.y ex de,hl // swap de,hl ld hl,(6+hitbox1) // hl = hitbox1.ymax add hl,de // hl = spr1.y + hitbox1.ymax ld b,h ld c,l // bc = hl ld hl,(2+spr2) // hl = spr2.y ex de,hl // swap de,hl ld hl,(4+hitbox2) // hl = hitbox2.ymin add hl,de // hl = spr2.y + hitbox2.ymin ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr nc,no_collid // if (spr1.y + hitbox1.ymax <= spr2.y + hitbox2.ymin) no_collid // ------------------ ld hl,(2+spr1) // hl = spr1.y ex de,hl // swap de,hl ld hl,(4+hitbox1) // hl = hitbox1.ymin add hl,de // hl = spr1.y + hitbox1.ymin ld b,h ld c,l // bc = hl ld hl,(2+spr2) // hl = spr2.y ex de,hl // swap de,hl ld hl,(6+hitbox2) // hl = hitbox2.ymax add hl,de // hl = spr2.y + hitbox2.ymax ld d,b ld e,c // de = bc or a // cf = 0 sbc hl,de // hl = hl - de - cf jr c,no_collid // if (spr1.y + hitbox1.ymin > spr2.y + hitbox2.ymax) no_collid .collid scf // cf = 1 jr end .no_collid or a // cf = 0 .end

Total : 560 cycles en cas de collision.

Ca pourrait sûrement être optimisé, mais à titre de comparaison il faut savoir que les opérations les plus rapides (par exemple un NOP) prennent 4 cycles sur un z80

Pour les structures c'est bien ça, il me semblait que c'était également celles de Touko donc j'ai repris les mêmes. Je te rassure en effet on peut faire plus rapide pour le Z80, mais on va dire qu'on est tous parti sur notre premier jet Wink

par Invité Dim 2 Fév 2014 - 22:07

Oui je pense qu'il faut définir un algo général et partir de là ..
Bien sur les avis de chacun seront bien venus pour fignoler l'algo .

car une approche autre que celle que j'ai pris peut tout changer .

celle que j'ai posté, c'est du pur bounding box appliquée à la lettre .

Mais je créerais un topic dédié demain .

par Stef Dim 2 Fév 2014 - 22:13

Nan mais je proposerai un algo normal, là j'ai juste posté un truc générique et en asm, donc comme le souligne stef pas exploitable ..

Je disais pas que ce n'était pas exploitable, c'est juste que je n'ai pas réussi à tout comprendre dans ton algo qui me semble bien compliqué pour une simple collision par bounding box. D'ailleurs pour le moment, c'est toi le plus en retard avec tes 360 cycles :p
Le Z80 avec ses 560 cycles est tout de même pas mal en dessous du ratio 2:1 qu'on peut attendre (et qui me semble plus réaliste que le 3:1 voir 4:1 qu'on lire sur les forums de fanatiques ^^).

stef: merci aussi de jouer le jeu .
pareil, si tu es parti de mon code, c'est peut être normal aussi ..
Mais je me doutait que le code 68k serait plus simple et plus lisible .
Toute ma tabulation est partie en couille quand j'ai fait le copier, de plus j'ai aussi mis les cycles à coté ..
J'essayerai de faire un truc plus user friendly la prochaine foi .

J'ai essayé de partir de ton code, le début est le même mais ensuite ton code semble faire des choses en plus que je ne comprends pas (en grande partie à cause de la syntaxe de cet assembleur tout à fait indigeste) donc au final j'ai finir par faire le code "classique" de la collision par bounding box. Sinon un poil plus de commentaires aussi pour aider c cool Wink

Astuce de sioux, mais je décrirais ce que je fais sans soucis .

Ca m'a fait penser au test qu'on peut faire pour de l'intersection mais je dois admettre qu'ici j'ai du mal à voir comment l'utiliser pour aller pus vite.
Bon en tout cas, j'attends ta prochaine version :p

par **TotOOntHeMooN** Dim 2 Fév 2014 - 22:14

Le mieux serait de demander à drfloyd de scinder le topic à partir du post de fano qui propose de comparer les CPU ainsi.

par Stef Dim 2 Fév 2014 - 22:16

TOUKO a écrit:Oui je pense qu'il faut définir un algo général et partir de là ..
Bien sur les avis de chacun seront bien venus pour fignoler l'algo .

car une approche autre que celle que j'ai pris peut tout changer .

celle que j'ai posté, c'est du pur bounding box appliquée à la lettre .

Mais je créerais un topic dédié demain .

Pour l'algo, celui que j'ai fait c'est le classique de la collision par bounding box et donc je pense qu'on peut s'en tenir à celui là :) Peut être que le tien est exactement le même mais j'avoue ne pas avoir réussi à tout comprendre, alors y'a tet une erreur de copier / coller aussi car je comptais bien plus que les cycles que ce que tu annoncais, ce qui expliquerait pourquoi j'étais perdu.

par Invité Dim 2 Fév 2014 - 22:35

@toto: merci ..

@stef: pour l'astuce de sioux, j'arrive plus à savoir pk j'avais fait ça (cette routine date de plusieurs mois), je vais m'en souvenir c'est sur, j'aurai du plus commenter ce passage .
Ce qui est sur c'est qu'elle marche, puisque je l'avais testée, et incorporée dans ma lib, il fallait juste que je l'optimise .

EDIT : j'en suis à 351 cycles avec 2/3 trucs superflux que je faisait, cette routine à vraiment été faite à la va vite ..

Et j'ai déjà des trucs en vue pour descendre bien plus bas .

@stef: les timings du 6280 sont plus élevés que ceux d'un 6502 ..

par **philip** Dim 2 Fév 2014 - 23:30

Peut être que notre ami touko a défini plusieurs zones de détection de présence du player, afin d' éviter de faire des milliers de tests de collision (qui seront pour la plupart inutile, donc).

Zona A...Zone B...Zone C

Si Xplayer < Zone B, alors autorise les tests avec les sprites de la zone A.

Ou encore une zone interactive englobant le player, afin d' exclure les sprites < Xzone or > Xzone

par Invité Dim 2 Fév 2014 - 23:47

Code:: lda <calc_pos + 1 and <calc_pos + 3 ; // Test 1ere colone x1 >= x2 eor <calc_pos + 5

Donc je viens de me rappeler, le and est fait sur les 8 bit de poid fort de x1 et x2 et le eor (xor) est fait avec l'octet de poid fort de x'2 ..
donc le and permet de savoir si la partie haute de x1 et x2 est égale et le xor si en plus elle est egale à celle de x'2, si c'est pas le cas, on évite de tester les 8 bit de poid faible de x1,x2,x'2

@philipp: c'est un peu ça, je joue sur la faculté de tester les bit de poid fort qui m'évite de tester ceux de poid faible inutilement si les conditions ne sont pas remplies .
En essayant de me remémorer ça, j'ai vu tout un tas d'optimisations simples qui vont bien faire baisser le total de cycles .

par fanoplusplus64K Lun 3 Fév 2014 - 9:33

Bravo les gars ! D'un troll vous avez fait un sujet passionnant !
C'est super intéressant de voir la manière différente d'aborder un problème selon le processeur.

par **Paradis** Lun 3 Fév 2014 - 9:53

On peut dire aussi
" Ah bah, bravo les gars! Vous avez fait d'un topic a troll super passionnant, un sujet super ennuyeux" Mr. Green

par vingazole Lun 3 Fév 2014 - 10:02

On peut aussi se traiter de singe si tu y tiens Twisted Evil