ericde45 (./20) :
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
Après test, et vérification, c'est effectivement ce qui se passe.
Il y a collision si le datacomparator retourne true.
le datacomparator retourne true si (!CMPDST && (source == pattern)) || (CMPDST && (destination == pattern))
donc si on a :
Source :
| 00 | 00 | 00 | 00 |
| 00 | 01 | 01 | 00 |
| 00 | 01 | 01 | 00 |
| 00 | 00 | 00 | 00
|
Destination :
| 08 | 00 | 00 | 08 |
| 08 | 00 | 00 | 08 |
| 08 | 00 | 00 | 08 |
| 08 | 00 | 00 | 08
|
et que l'on combine source -> destination en testant le 08 comme pattern de destination, pour obtenir quelque chose comme ça :
| 08 | 00 | 00 | 08 |
| 08 | 01 | 01 | 08 |
| 08 | 01 | 01 | 08 |
| 08 | 00 | 00 | 08
|
On aura forcement une collision causée par le pixel Dest[0,0] == pattern.
Je ne vois pas de solutions pour ignorer les pixels sources inactifs tout en testant un pattern sur la destination.
Il faudra le faire donc en 2 passes : la première pour combiner, la deuxième pour chercher un pattern de collision.
C'est dommage que la comparaison ne se fasse pas sur le résultat du LFU, sinon ça aurait pu être fait en une seule passe.
Les coordonnées retournés par A1 et A2 sont les coordonnées du pixel suivant (X+1;Y).
Je n'ai pas vérifier dans le cas où le pixel en collision est le dernier de la ligne de voir si on a (X+1;Y) ou (X; Y+1) ou (X; Y).
Fichier joint : collisions.s
Fichier joint : collisions.s
