detection de collision par le blitter - Page 1

bonjour tout le monde,

j'ai lu avec interet le sujet suivant sur Atariage : https://atariage.com/forums/topic/64182-collision-detection-of-objects/?tab=comments#comment-790005

et j'avoue que je ne capte par un element.

je partirai sur l'idée de prendre une zone mémoire mise à zéro à chaque VBL, d'y blitter les ennemis en 1 plan.
je copie cette zone dans une 2eme zone
sur la 1ere zone je blit les tirs des ennemis toujours en 1 plan
tout cela sans aucun test de collision
je blit ensuite le personnage avec test de collision ( en 1 plan )
je sais donc si mon perso est en contact avec un ennemi ou un tir ennemi => paf pouf il est mort

sur la 2eme zone je blit les tirs du joueur, avec test de collision, si collision => paf pouf l'ennemi est mort ( avec une jolie recherche de l'ennemi concerné suivant les X et les Y)

je n'ai pas trop utilisé le blitter a part pour copier du code dans le gpu ou le cpu, mais a priori on peut blitter un bitmap sans vraiment l'écrire. donc ça me permettrait de tester chaque tir du joueur sans tester de collision entre les tirs du joueur ( puisqu'ils ne sont pas vraiment blittés dans la zone mémoire de test )

or dans ce lien sur Atariage, il est écrit : "every object a different colour, so you know which object it hid." ( je suppose que c'est HIT à la place de HID)
or dans la joc jaguar je ne vois pas comment lier couleur et collision, la collision semble uniquement être un arrêt net si le pixel de destination n'est pas à zéro et que le pixel source n'est pas non plus à zéro

bien sur, pour l'instant je ne fais aucun essai
( j'ai fait un scrolling de tiles à partir d'une map dernièrement : )

Quand tu actives le mode collision, il faut qu'il y ai au moins BCOMPEN (bit comparator), DCOMPEN (data comparator) ou ZMODE (Z comparator) d'activé.
Selon le mode, tu as donc une comparaison entre une source/destination qui peuvent être en RAM (si un des SRCEN<> ou DSTEN<> sont activés) ou sinon ça sera via les registres (SRCD, DSTD, DSTZ, SRCZ, PATD)

Donc tu peux comparer avec des valeurs ou des bits, fixes ou non, selon ton besoin.
Lorsqu'il y a une "collision", le blitter se met en pause et tu peux lire les registres PIXEL (par exemple) pour savoir les coordonnées de collision.
Après il faut :
- soit le relancer via "RESUME" et il va reprendre là où il était et de nouveau se mettre en pause si une nouvelle collision arrive.
- soit l’arrêter via "ABORT". En général si c'est pour détecter une collision entre sprite, c'est celui là qui est utilisé car y a pas besoin de connaitre toutes les coordonnées de collision.

Me souviens plus par contre si la collision génère une interruption ou si il faut lire régulièrement le registre associé..

ok donc si j'ai bien capté, après arrêt du blitter, si le flag de collision est UP, je peux aller lire la couleur du pixel de Window Pixel Pointer et déterminer ce qui était présent sur ma destination

je vais me faire un prototype très progressif car ayant beaucoup codé sur STF, le blitter est un inconnu pour moi

En fait c'est le contraire : il faut indiquer au blitter sur quel "couleur" il doit s'arrêter.
La collision est généré lorsqu'il y a un "write inhibit" qui a lieu lorsque la comparaison est vrai (ie == dans le cas de DCOMPEN par exemple)

j'ai du mal à saisir un point : puis je blitter un objet dans une zone avec test de collision ? comme si j'affichais un sprite sur une zone mémoire ou il y a deja des pixels et si il y a un pixel il s'arrête ?

ou est ce une recherche de couleur que je mets dans "Pattern Data Register" ?

je regarderai ce soir comment j'ai implémenté le blitter.
Mais possible que je me suis un peut embrouillé dans ./2

merci
j'ai commencé du code pour faire des tests concrets.
mais ton aide, et celle de tous ceux qui s'y connaissent, est très bienvenue !

mes tests de l'après midi :

tout est en 8 bits - 256 couleurs

- déjà 1er point : pour faire un sprite au blitter je dois faire 2 passes, AND entre et masque inversé du sprite, puis OR du sprite sur le fond
y a t il un moyen plus rapide en 1 passe pour faire un sprite au blitter , avec les formules tordues du LFU ?

- 2eme point : pour tester j'ai réussi à faire fonctionner la collision : je blit fond OR sprite, avec des masques unicolor. donc si j'ai couleur du fond quand il y a un pixel allumé =1 et couleur du sprite = 8 , le OR donne 9
et ensuite je fais un test de collision sur la zone, avec comme data pattern = $09 et si mon sprite de couleur 8 est sur mon fond de couleur 1, j'ai bien une collision detectée

il faut que le test de collision de la destination soit une opération LFU B_DSTD sinon on modifie le fond avec le data pattern.

je ne sais pas pour l'instant comment déterminer le pixel concerné, A1 pixel et A2 pixel me retourne -1 après collision ....

j'ai essayé en ajouter un abort avant de lire A1_PIXEL, pas de changement
move.l A1_PIXEL,d1 => donne -1 dans d1

sous phoenix je vois une autre valeur dans la variable de l'émulateur nommée : a1_pixl

est ce que je me trompe pour lire une variable du blitter ? il y a une astuce ?

Pour le 1er point, il est possible de faire tout en une seule passe.
en supposant que :
- 0x0000 = transparent

Je ferai quelque chose comme ça : (uniquement en mode PIXEL et non PHRASE)
B_CMD :
- SRCEN => activation de la lecture data source
- DSTEN => activation de la lecture data destination
- LFU_REPLACE => écrire SOURCE
- DCOMPEN => activation du test "if B_PATD = source"

B_PATD
- initialisé avec la valeur "0x0000 0000 0000 0000" (64-bit)


En théorie, le blitter devrait effectuer les opérations suivantes :
move.w (a2), B_SRCD move.w (a1), B_DST cmp.w B_SRC, B_PATD beq.s .inhibit .no_inhibit: move.w B_SRCD, (a1) bra.s next_pixel .inhibit: bra.s next_pixel
Du coup :
lorsque la source lue n'est pas égal à PATTERN, la source est écrite
lorsque la source lue est égal à PATTERN, la source n'est pas écrite : la destination reste intacte.


--------------------------------------
Pour la collision, il est aussi possible de faire tout en une seule passe.
en supposant que :
- 0x0000 = transparent
- 0xAAAA = data sprite source
- 0xBBBB = data sprite destination à rechercher

Je ferai quelque chose comme ça : (uniquement en mode PIXEL et non PHRASE)
B_CMD :
- SRCEN => activation de la lecture data source
- DSTEN => activation de la lecture data destination
- LFU_SORD => écriture SOURCE | DESTINATION
- CMPDST => activation de la comparaison avec destination
- DCOMPEN => activation du test "if B_PATD = destination"

B_PATD
- initialisé avec la valeur "0xBBBB BBBB BBBB BBBB" (64-bit)

B_STOP
- STOPEN => activation du mode collision


En théorie, le blitter devrait effectuer les opérations suivantes :
move.w (a2), B_SRCD move.w (a1), B_DST cmp.w B_DST, B_PATD beq.s .collision .no_collision: move.w B_SRCD | B_DSTD, (a1) bra.s next_pixel .collision: wait btst #ABORT, B_STOP beq.s stop btst #RESUME, B_STOP bra.s next_pixel
Du coup :
lorsque la destination lue n'est pas égal à PATTERN, la source | destination est écrite
lorsque la destination lue est égal à PATTERN, la source n'est pas écrite : la destination reste intacte et le blitter se met en pause.


Après, il faut voir si ça répond à ton besoin (et si ça marche : j'ai pas testé)


-----------------------------------------------
Pour ta question sur A1_PIXEL, c'est normal car il y a un bug du coup A1_PIXEL & A2_PIXEL ne sont pas à lire à la même adresse que l'écriture :
A1_PIXEL_R : F02204 (au lieu de A1_PIXEL_W : F0220C)
A2_PIXEL_R : F0222C (au lieu de A2_PIXEL_W : F02230)

un grand merci !

Ta solution pour le sprite en 1 passe fonctionne, testée immédiatement et OK !
( c'était purement intellectuel, je fais mes sprites en OL bien sur )

je testerai dès demain la collision en 1 passe.

edit : la lecture de A1 et A2 pixel fonctionne aussi, j'ai retrouvé ça dans la liste de bugs en pdf
par contre je ne sais pas interpréter ce que je lis comme valeurs. en promenant la zone de collision, ça ne semble pas trop claire. A suivre...

bonjour

après test, ce que tu as proposé affiche les lignes avant collision, et s'arrête avant d'afficher la ligne de collision ( mes tests sont en 16x16)
donc en mettant B_DSTD à la place de LFU_SORD, ça ne modifie pas le fond

par contre j'ai un bug avec Phoenix
après une collision, avec ou sans abort, le prochain sprite est décalé vers le bas

sur la Jaguar ça ne le fait pas

je pense que phoenix ne remet pas à zéro un registre du blitter, mais lequel ???

par exemple ici les 2 sprites roses verticaux sont blittés à la même hauteur
celui de droite est blitté après collision+abort


le bord rouge montre que la 2ème collision a été detectée


sur phoenix :



sur la Jaguar :

donc je suis pas si rouillé que ça

si tu veux continuer à te dérouiller, je suis preneur de réponse pour savoir

- quel registre peut foutre le bazar dans phoenix pour qu'il n'affiche pas le sprite qui suit le test de collision, au bon Y ?

- comment interpréter les valeurs lues dans A1_pixel et A2_pixel ? si je me dis que c'est Y.w et X.w, ça ne colle pas

et pour te motiver, mon code de test est là : https://github.com/ericde45/JAG_collisions

( c'est surtout pour aller au fond des choses et tout comprendre )

Je me disais bien qu'il y avait un truc que je comprenais pas dans ton ./12
B_DSTD = 0xF02248, du coup vu que tu l'utilises dans l'init de B_CMD, le blitter doit faire un peut n'importe quoi (ou en tout cas, pas ce que l'on pense) je pense que tu as du te tromper avec LFU_D ou un truc du genre

Là où tu lis A1 & A2 pixel, même si c'est fonctionnel sur une vrai jag car le blitter freeze le 68k, vaut mieux le mettre après avoir vérifier que le blitter est bien en pause : typiquement sur Emulateur je ne sais pas si c'est bien implémenté (et si tu veux faire la même chose sur GPU, ca sera pas bon ).

Sinon A1 et A2 sont bien sous la forme (Y.w,X.w) en lecture, mais comme le blitter doit faire un peut n'importe quoi avec le B_DSTD, ça doit du coup correspondre à des coordonnées incohérentes.

oui le B_DSTD est une erreur
une fois corrigée ça ne change rien , phoenix affiche toujours le sprite post test de collision décalé en Y
il faudrait que j'affiche A1 et A2 prixel sur la console.

oui je ne fais aucune attente de blitter au 68000. c'est d'ailleurs super pratique !

pas sur que je bascule cela sur le GPU, je vois pas trop ce que ça va vraiment changer de faire quelques comparaisons et l'activation du blitter au GPU. je préfère garder la ram gpu pour avoir mon tableau qui me sert à créer, au GPU, mon OL

Si les photos d’écrans correspondent au code, je ne comprend pas les résultats obtenus car, dans le code je vois :
- effacement de la "zone_fond"
- dessin méthode 1 "sprite_fond" aux coordonnées (32 x; 40 y) => ce qui semble correspondre au "pause" rose de gauche
- dessin méthode 2 "sprite_fond" aux coordonnées (49 x; 80 y) => ce qui semble correspondre au "pause" rose de droite sur Phoenix mais pas sur la jag
- dessin "sprite_rond" aux coordonnées (25 x; 55 y) => ce qui ne correspond pas à ce que l'on voit sur les écrans
- dessin "sprite_rond" avec collision aux même coordonnées (25 x; 55 y) => ce qui ne correspond pas à ce que l'on voit sur les écrans

Néanmoins, je pense que le soucis vient du fait que les A1_pixel n'ont pas les bonnes valeurs : en théorie ça devrait être pareil, mais en interne au blitter il y a probablement des overflow (je n'ai pas vérifié car c'est compliqué à vérifier vu que ca dépend des pixel mode etc).
Pour avoir les bonnes coordonnées, il ne faut pas écrire "(320*40)+32" mais "(40<<16)|32".
Car en fait sinon on a en interne du blitter : Y = 0 et X = 12832 au lieu de Y = 40 et X = 32

Peut-être que le soucis vient de là

ok, ou faire des swaps.
ça vient du fait qu'avant je positionnais les sprites en modifiant A1_BASE
merci !

c'est identique avec une bonne forme de données pour A1 pixel et A2 pixel
la jaguar et ses mystères...

hello

bon j'ai repris le problème et je seche

j'ai mis un bloc de 4 pixels 2x2, entre 2 colonnes verticales, et il ne doit pas y avoir de collision
or quoi que j'essaye il y a collision ou jamais de collision, même quand j'en force une

j'écris bien dans B_PATD et B_PATD+4

j'ai testé avec pattern = couleur du fond deja blitté
sur la jaguar directement

j'ai l'impression que dès que le blitter lit une zone avec la valeur de fond, et que même si il ne va pas l'écraser par la valeur de la source, si la source = 00 pour ce pixel qui n'est pas a zéro sur le fond, il voit une collision

j'ai mis à jour mon test sur mon github : https://github.com/ericde45/JAG_collisions

ça serait quand même bien d'en avoir le coeur net, comprendre comment fonctionnent les collisions au blitter car je ne suis pas sur que quelqu'un les ait vraiment utilisées un jour.
( la doc V8 PDF est floue, et sur https://www.mulle-kybernetik.com/jagdox/blitter.html et https://www.mulle-kybernetik.com/jagdox/tutorial.html , il n'y a pas d'exemple de test de collision )

A ma connaissance, il n'y a quasi (voir probablement aucun) jeu officiel qui utilise ce mode.
je n'ai pas encore implémenté cette fonctionnalité dans le blitter de la jagfpga et j'ai une bonne compatibilité avec les jeux.

Je testerai ce weekend.

peut etre que justement comme c'était obscure , tout le monde est resté sur du test sur de la hitbox
c'est quand même dommage !
même si beaucoup de dev sont partis vers de la 3D donc moins de besoin de test de collisions a priori
la Jag est quand même une bête pour la 2D

merci d'avance pour ton expertise !

ericde45 (./20) :
ça serait quand même bien d'en avoir le coeur net, comprendre comment fonctionnent les collisions au blitter car je ne suis pas sur que quelqu'un les ait vraiment utilisées un jour.

Si tu as beaucoup de courage, tu peux te plonger dans les netlists pour décortiquer ce que fait le blitter exactement...

D'ailleurs SCPCD, tu avais analysé les netlists pour ta JagFPGA, ou tu as tout refait d'après la doc ? Je me disais que ce serait bien de les transformer en quelque chose de plus lisible, mais tu l'as peut-être déjà fait.

je doute que avec 0 heure de formation en électronique dans ma vie, ce soit viable de se lancer là dedans

Zero > j'ai analysé les netlists oui pour comprendre le fonctionnement de certains trucs, et corrigé des bugs dans mon implémentation.
Mais mon implémentation n'a absolument rien à voir avec le blitter original (comme le reste d'ailleurs : c'est juste registre/instruction compatible).

Faudrait que je trouve le temps (et surtout le courage) un jour de faire une documentation de comment tout ca fonctionne.

Ce serait génial, mais c'est un travail de titan...

Je pense que rien que convertir le texte sous forme graphique et rajouter des commentaires (notamment avoir une table avec chaque signal et sa fonction) serait déjà un grand pas. Parce que sous la forme texte actuelle, c'est prise de tête à lire.

SCPCD (./25) :
Zero > j'ai analysé les netlists oui pour comprendre le fonctionnement de certains trucs, et corrigé des bugs dans mon implémentation.
Mais mon implémentation n'a absolument rien à voir avec le blitter original (comme le reste d'ailleurs : c'est juste registre/instruction compatible).

C'est quoi l'intérêt d'ailleurs ? De corriger les bugs. Du coup tu n'es plus compatible avec la vraie Jag et il risque d'y avoir des jeux qui ne tournent que sur ton implémentation 🤔

Je pense qu'il voulait dire : les bugs de son implémentation, pas les bugs d'origine

oui
quand je me suis relu après avoir posté, je me suis rendu compte effectivement que ça pouvait prêter à confusion, mais j'ai eu la flemme de reformuler

(après, il y a quand même quelques bugs originaux qui ont été corrigés mais ça impacte quasi pas les jeux originaux)

Sinon y'a la solution de la Jaguar II, les bugs à la carte :