Sur la Jag on a tout pour ètre heureux sauf.........pour les collisions de sprites, donc j'aimerais savoir si certains y ont déjà pensé. Comme technique on aurait :



- Bouding boxes (Tester des cubes)

- Bouding circles (Vérifier sur un cercle)



Quelqu'un a autre chose ?



GT Turbo :blush:

Ptet avec le blitter ?

En faisant un mask et en lui faisant tester pixel par pixel ?

J'avais pensé a voir pour adapter la routine de P. Mandin, mais je trouvais cela délirant de devoir 'fabriquer' un mask pour faire les tests !! C'est vrai que l'avantage de cette routine, c'est le test au pixel près, mais faut voir suivant les cas, on va perdre du temps machine a faire les masques. Sinon faudrait fabriqué les masques durant l'init du jeu, faut voir avec la ram dispo, moi qui reve depuis longtemps de faire des gros gros sprites !!



GT Turbo ;)

Sinon, il y a ptet moyen (mais compliqué) en couplant le GPU avec le OP (verification de ce qu'il fait dans la Line Buffer a des moments stratégiques ?)

Idee super bonne, mais j'ai peur d'un truc, on va perdre un certain temps a faire du scan sur la line buffer, surtout qu'il faut le faire ultra vite, pas qu'on se retrouve avec la prochaien ligne alors qu'on a pas fini de tester la notre !!



Balancé les idées, on fera un tri un peu plus tard



GT Turbo

Tu peux utiliser les objets GPU dans la liste des objets a des endroits strategiques (qui lancent une interruptions au GPU) comme sa tu peux deja savoir un peu plus précisement ce qui a dans la Line Buffer...

En plus, dans la Technical Reference Manual de Tom & Jerry, dans la section LBUFF ils disent qu'il y a une zone adressable en 32bits pour justement que le GPU puisse aider le pross d'objet a faire du traitement sur l'affichage.

De plus, c'est du double buffer donc un sur la ligne en cours et l'autre sur la ligne precedente : comme sa, tu peux toujours verifier sur la ligne precedente alors que l'OP travaille sur la ligne suivante.



Mais il faut donc faire un code vraiment hyper rapide comme tu dis ;)

La collision de sprites pour faire quoi ?



- un rebond ?

- une explosion ?

Pour tous les cas de figures, ca serait bete de se retrouver bloquer pour des questions de collisions maintenant qu'on a pratiquement tout.



GT Pour lister les idées ! ;)

Et avec les splines ?



Comme sa on prend des points particuliers des objets et la spline represente l'approximation de la forme de l'objet.

Il suffit alors de verifier si il y a intersection des splines des objets et le tours est joué.



Il faut prendre les splines les plus simples : les splines cubiques normalisées relaxées qui ce calcul facilement. On les calcul au chargement par exemple et voila !



ensuite, il suffit de faire une premiere verification pour pouvoir choisir les bonnes parties des splines a tester et ensuite on verifi si il y a intersection ou non.



L'avantage c'est qu'avec tous les types de prog 2D sa fonctionne.

C'est une idée. Tu es prêt à chercher les racines de polynômes du troisième degré définis par morceaux ?



Je préfère pour ma part la technique :

- on cherche l'intersection de boites englobantes

- s'il y a intersection, alors on teste la collision avec des masques

:wacko:



J'ai oublié ce point.....:wacko:

En train d'écrire la gestion de liste au Gpu, je me suis apercu que je pouvais intégrer la routine de collision directement dedans, vu que pour chaque objet, dans la description on possède sa position et sa taille, après il n'y aurait plus qu'a tester si intersection, si oui 'XOR ER' les masques et voir le résultat, il ne reste plus qu'a generer les masques, la génération doit pouvoir se faire en automatique, histoire de pas se prendre la tete, je recoderais surement les masques true color en bit, cela permet de diviser par 16 la taille par rapport au sprite (1 bit=1 pixel) et pour faire le 'XOR' cela accellera aussi le traitement.



GT Turbo ;)

oulà ça devient trop balaise pour moi ici ... avec mon Bac ES et mes 4 en math , je préfère fairte profil bas B)

Traduction pour ceux qui ont pas bac+12, l'opération consiste juste a faire une opération logique entre les masques (Sprite en deux couleurs, noir et blanc ou noir et une couleur pour les points), le résultat de cette opération donne 0 si les sprites se touchent pas et 1 si ils se touchent (Voir sur le site de Patrice Mandin), si mes souvenirs sont bons il explique le principe en plus détaillé. L'avantage que cela permet c'est du test de sprite au pixel près, plus de 'P...... de jeu de m...... j'ai explosé et pourtant le tir est passé a coté '





GT Turbo ;)

Salut,

avec GT, on va bientôt rendre disponible la routine de collision "au pixel près" écrite au GPU. Elle marche pour les sprites 16 bits mais ne gère pas les champs PITCH ou REFLECT. La méthode utilisée est inspirée de l'idée de Patrice Mandin sauf qu'elle ne construit pas de masque explicitement .

Cela dit, je suis persuadé qu'on peut faire une routine plus générale au blitter qui marcherait dans tous les cas de figure (1 bit -> 32 bits, avec gestion de PITCH et FIRSTPIX). L'idée serait de faire générer au blitter le masque (avec un des deux modes de comparaison du blitter). Ensuite, on pourrait probablement refaire le même genre de trucs avec le deuxième sprite mais cette fois en utilisant le mode "collision detection" (qui porte surement bien son nom )
Bon, je ne sais pas si on gagnerait en vitesse par contre, et je ne sais pas non plus si ça serait utile en pratique d'avoir la routine "la plus générale" possible.

Et puis bon, 'faut comprendre notre ami le blitter avant ça .

Seb

Je fais tourner mon code, et pourrait enfin faire le dernier test de ton code SebRmv



GT Testeur

Les collisions de sprite sur Jag, une galère ? Et bien fini les galères pour les colisions, bien parce que vous le valez bien, avec SebRmv vu qu'on s'ennuyait, on vous a concocté une routine super sympa, qui fait du test de colision au pixel près ! Et oui fini les 'pourtant je l'ais pas touché !'. Combien de fois avez vous déjà criés cela en jouant, n'est ce pas ! Enfin bon voila c'est une histoire passé, au passage un merci a Mandin Patrice pour l'idée (Au passage c'est du code Gpu)

Allez y de bon coeur : Click to view attachment


SebRmv et GT

Et le clipping façon BLITTER, quelqu'un a testé ?

Tu veux parler du registre de colision du blitter ? Si c'est cela je crois bien que SebRmv a une petite idée dessus


GT

oh là, t'emballe pas GT
c'est clair que ça doit être possible
mais j'ai pas encore d'idées claires
sur la chose

Seb

Je m'emballes pas, je voulais juste dire que tu y avais un peu pensé, mais la je vous avoues que je serais super curieux si quelqu'un arrivait a faire quelques chose avec le blitter, pour les colisions


GT Très curieux

bon, c'est bon alors
moi aussi, j'aimerais bien la pondre cette routine au blitter!!

Seb

La première analyse vite fait avant de m'endormir me fait encore (et toujours) demander si c'est possible du moins rapidement, car :

- Pour que le blitter puisse tester cela, nous avons a parcourir une source (On va dire que c'est le premier sprite a tester) et a écrire sur une destination (on va dire le second sprite a tester) pour faire le test donc, deux choses apparaissent :

- il va falloir faire une copie du second sprite quelque part pour éviter d'écraser notre second sprite
- le mode de colision n'est possible qu'en pixel mode le mode le plus lent du blitter

Ce qui indique a première vue une routine pas super rapide, non ?

GT

ouais, j'ai l'impression aussi qu'on n'y gagnera pas forcément...

Seb