rotations - Page 1

salut
j'ai fait une routine pour une rotation d'un sprite de 16*16 avec comme centre de rotation le point (8,8) dans ce sprite. Ca marche mais y'a plein de trous dans le sprite final, et on m'a dit que c'était pas forcemment la bonne méthode, alors je viens chercher des idées
voici mon code:
Bon, c'est surement très mal fait mais j'ai juste cherché à ce que cela marche, alors ...
si vous voyez comment résoudre mon problème, allez y
(ici, c une rotation fixe de 90 degres, mais j'implanterai une table + tard )
merci d'avance


[edit]Edité par gugusg le 16-12-2001 à 20:38:26[/edit]

il y a truc aussi avec les sinus mais bon je ne m'en souviens plus donc je ne pense pas que cela ai un rapport avec ta question

La meilleure façon c'est l'inverse... tu prend un point sur l'écran et tu regarde à quel pixel de ton sprite ça correspond, comme ça t'es sur de ne pas te retrouver avec des trous à la fin

c donc cela cette "fameuse" méthode

même principe ke le texture mapping, on y revient encore

muls #0,d0
muls #-256,d1
muls #-256,d2
muls #0,d3

j'adore ces lignes. Tu as fait un effort particulier, non ?

???
c juste que ca va etre remplacé par une table, alors je voit pas le prob

ok,ok... c'est la valeur de tes angles, c ça?
bah, d'accord... ms quand même, 6 multiplications... tu dois pouvoir faire + simple et + rapide qd même... déjà tu pe en virer deux qui servent pas à grand chose...
tes deux muls #2,dx, bah tu fé add dx,dx c qd même mieux

celle là, j'allais les virer
mais les 4 autres, je vois pas

Est-ce que ces valueurs sont suceptibles de varier ?
Sinon rappel :
0 x 1 = 0
0 x 2 = 0
0 x 3 = 0
0 x 4 = 0
0 x 5 = 0
0 x 6 = 0
...

Pour les muls, fais des lsl à la place...

lol le rappel
c vrai que des muls #0 c rare de voir ça

Et moi qui pensais que clr.l était la manière la plus lente d'effacer un registre de données... Je me demande si on peut trouver pire que muls #0,dn...

mais nan! vs avez pas compris son code ou koi?
regardez le titre du topic! "rotations" ok?

tous ces muls, a mon avis, servent à effectuer cette rotation, enfin, il me semble... il a du mettre ça en attente d'une table précalculée de sin/cos
dc en fait, ça sert à rien qu'il optimise ça, ça lui donnera une fausse idée de la vitesse finale quand ça variera... apparemment de 256 à -256

laisse les, va ! ils ont pas lus la phrase imporante :
Bon, c'est surement très mal fait mais j'ai juste cherché à ce que cela marche, alors ...

la vraie question est celle ci : comment on passe de la forme finale (comment l'obtient-on), et comment fait on pour la remplir correctement après.

si on a un truc comme ça à l'arrivée :

   8
  888
 88888
  000
   0

j'éspère que ce shéma va rendre qqchose

heuresement que Sbibi comprend quelquechose
sinon, je pense avoir compris l'autre méthode donc tout baigne

j'ai aussi compris la question, mais le schéma est tout pourri et moche, désolé.

si t'as compris une méthode, tout baigne alors

toi aussi rv
oué, je pense avoir compris, mais je pourrais vérifier que ce week-end
en fait j'ai mis longtemps à comprendre un truc du fait que le sprite fait 16*16, donc si le centre est au milieu ca merde un peu (en fait y'a pas vraiment de milieu )
mais je pense avoir compris, donc tout baigne

CETTE ROUTINE MARCHE PARFAITEMENT
Si vous voyez des améliorations possibles, faites moi signe s'il vous plait
me demander pour la routine
[edit]Edité par gugusg le 30-12-2001 à 22:51:50[/edit]

bon, déjà, ça n'a aucun rapport avec ton pbl, mais pkoi tu recalcules les sin/cos dans TA BOUCLE D'AFFICHAGE ?????

fais le à l'extérieur, ils ne changeront pas!
tu sauvegardes les valeurs trouvées et tu fé tes muls dans ta boucle...
pareil pour tous les lea! pas besoin de les refaire à chaque itération de la boucle!!
sinon, ton bug, j'en c rien, chuis cmpltm naze là, et v dormir... @+ bonnuit

sBibi > g pigé ce que tu veut dire
sinon pour mon pb
personne

ben non, on dirai personne

bah déjà essaye de l'écrire en basic, ça doit être une couille avec les conditions... ptet un bge au lieu d'un bgt, des trucs comme ça...
t'essayes de voir d'où vien le pbl en basic, et après tu corriges dans ton code asm

oué, mais c bizarre que ca couille que pour le 180°

pour le 90 et -90° y'a pas de pb !!

qua pour 180° hein? dis moi, quand tu dépasses un angle de 180 °, ça fé koi?
ça mets -180° dans l'angle, -179 ° ? 181° ?
tes angles vont de koi à koi?
0/360 ?
-180/180 ?

et, je v peut-être dire une connerie, mais le pbl pourrait venir de là:

 cmp #0,d3	      ;on verifie que x et y sont dans le sprite
  blt continue
  cmp #15,d3
  bgt continue
  cmp #0,d0
  blt continue
  cmp #15,d0
  bgt continue

pourquoi tu fais ces tests? c'est por vérifier que la position calculée des points est dans le sprite non? je pense pas que ça serve à grand chose... si tu le vires, ça devrait faire pareil, vu que la position calculée sera toujours dans le sprite...
et essaye en remplaçant tous les blt/bgt par ble/bge dans le bout de code ci-dessus, voir ce ke ça fait...

pour les autres rotations proches je sais pas > y'a la deformation et on voit pas trop
pour les tests> ben si
1- je prend tous les octets un par un du sprite d'arrivée
2- je fait la rotation inverse
3- JE TESTE S'ILS SONT BIEN SUR LE SPRITE DE DEPART et si c un blanc ou un noir
4- je change ou pas le bit sur le sprite d'arrivée

Si je fait pas le test ca risque bien de foirer pour le test sur le sprite d'arrivée (vu que je teste entre les bits 0 et 15)

mais si tu prends les points du sprite d'arrivée et que tu les rotate, ils seront dans le sprite de départ!
à mon avis y a pas besoin de tt ça...
et essaye ble bge à la place de blt bgt

ben pas forcement
si on prend un angle et que tu fait une rotation < à 90°, il sera pas dans le nouveau sprite
je vais essayer les bge et ble sans conviction

g peut etre compris mais faut que je verifie