rotation - Page 1

salut , c'est encore moi ! j'ai l'impression que y'a plus grand monde qui s'interesse a l'asm68k

j'essaie de faire une petite fonction de rotation vraiment rapide en asm (pour l'instant elle est en basic ) et elle marche pas à tous les coups .. snif...

mais je suis pas tres sur de ma methode qui reste relativement lente :

on prend un pt M(x,y),un centre de rotation O(xo,yo),et un angle A de rotation, un sens de rotation
on prend M en polaire par rapport a O :
M(sqrt((x-xo)²+(y-yo)²)=R,ArcCos((x-xo)/R)=thêta)
a M on enleve ou on retire l'angle A en fonction du sens de rotation
ensuite on obtient M' (x'=R*cos(theta(+-)A)+ox,y'=R*sin(theta(+-)A)+oy)

ca vous parait bien ??
est ce qu'il existe un autre moyen plus rapide ?
et est ce qu'il existe une methode pour ne pas faire faire point par point (j'aimerais faire tourner l'ecran en entier ! )

l'asm 68k comme la dev sur ti est morte

1: c'est pas le lieu pour placer ce genre de choses.
2: c'est pas ce qu'il demande
3: tant qu'il y a des codeurs, il y a de la vie

3: et inversement

bon j'ai un probleme un peu plus simple : je n'arrive pas a calculer la partie entiere d'1 racine carré avec cette 'fonction'
dans d0, on met le chiffre
dans a0, on met l'adresse ou on doit stocker le resultat

sqrt_:
movem.l %d1-%d4,-(%a7)
moveq.l #0,%d4
moveq.l #1,%d1
moveq.l #1,%d3

clr.w %d2 ; le compteur

boucle: do{
add.w #1,%d2 , d2++

sub.w %d0,%d1
move.w %d1,%d0

add.w #2,%d3 ; +2 pour etre toujours impair

move.w %d3,%d1

cmp %d0,%d4;} while(d0>0);
bgt boucle

move.w %d1,(%a0)
movem.l (%a7)+,%d1-%d4	

enfin je veux dire qu'elle marche pas alors que j'ai fait tout pareil en basic

bon ok pour la rotation ntome m'a aidé et chuis tombé la dessus

x'=cos(A)*x - Sin(A)*y + ox(1-cos(A))+ oy*sin(A)
y'=sin(A) *x + cos(A)*y- ox*sin(A) + oy(1-cos(A))

ca vous parait bon ?

C'est une mauvaise idée de faire ça avec les images, il vaut mieux faire ça avec les antécédents (rotation réciproque), ça donne une image de meilleure qualité.

euh... et c'est ca les "antecedents" ?? :

char source[LCD_SIZE],cible[LCD_SIZE]; 
int x,y,sourcex,sourcey,dmax,xmin,xmax,ymin,ymax,centrex,centrey; 
__complex__ float expmoinsitheta,sourcexplusiy; 
memcpy(cible,LCD_MEM,LCD_SIZE); 
PortSet(source,239,127); 
/*** AFFICHAGE D'UN FICHIER PIC (VOIR TIGCC) ***/ 
PortRestore(); 
/*** PLACE LES DIMENTIONS X & Y DU PIC DANS COMMANDES[8] & [9] ***/ 
sincos(-commandes[6],1,& __imag__ expmoinsitheta,& __real__ expmoinsitheta); 
centrex=commandes[2]+commandes[4]; 
centrey=commandes[3]+commandes[5]; 
dmax=commandes[8]+commandes[9]-2; 
xmin=max(centrex-dmax,0); 
xmax=min(centrex+dmax,239); 
ymin=max(centrey-dmax,0); 
ymax=min(centrey+dmax,127); 
for(x=xmin;x<=xmax;x++) 
for(y=ymin;y<=ymax;y++) 
{ 
sourcexplusiy=((float)(x-centrex)+1.0i*(float)(y-centrey))*expmoinsitheta; 
sourcex=(int)(__real__ sourcexplusiy)+commandes[4];sourcey=(int)(__imag__ sourcexplusiy)+commandes[5]; 
/* Là, dans ta source, commandes[4] et commandes[5] ne seraient pas ajoutées, mais je pense que c'est une erreur. */ 
if((sourcex>=0)&&(sourcex<commandes[8])&&(sourcey>=0)&&(sourcey<commandes[8])) 
{ 
if(EXT_GETPIX(source,sourcex,sourcey)) EXT_SETPIX(cible,x,y); else EXT_CLRPIX(cible,x,y); 
} 
} 
LCD_restore(cible); 

Oui, c'est la méthode des antécédents, et codée avec des nombres complexes. Tu verras que je travaille avec expmoinsitheta alors que tes formules sont équivalentes à exp(i theta). L'idée, c'est de prendre un pixel de la destination et de regarder à quel pixel source il correspond, pas l'inverse. Comme ça, tu es sûr de couvrir tous les pixels de la destination une et une seule fois.

c vrai que c'est bien mieux ! merci kevin, toujours la pour filer des bon tuyaux !!!
maintenant y'a plus qu'a faire ca en asm !

quant a ma fonction racine, j'arrive pas a piger pourquoi elle marche pas, elle a exactement la meme organisation que en basic ...

j'aimerais bien comprendre, à quoi correspondent les "commandes" dans le post 4 ?

ba en fait cette fnc permet de caculer la partie entiere d'une racine carré : on sait que la some des n premiers impairs est egale a n²

donc en fait on fait une boucle, a chaque passage dans la boucle on increment un compteur I
et on enleve a chaque iteration au chiffre de depart K la somme des I premiers entiers,
si il est negatif ou egal a 0 alors int(sqrt(K))=I on a le resultat

donc %d0 est le chiffre
%d2 est le compteur
%d3 et %d1 permettent de stocker la somme des entiers impairs
on ajoute 2 a %d3 a chaque iteration pour qu'il reste impair ( il est initialisé a 1)
et %d4 est tjours = 0 pour le cmp

cmp %d0,%d4;} while(d0>0); 
bgt boucle 

pas tres efficace tout ça

cmp d0,#0


serait deja mieux, ensuite sache que bxx se base sur l'état du registre d'état, donc

move d0,d0 pourrais meme suffire sachant que bgt ne fait que tester si le dernier resultat est différent de 0 et qu'il est positif

en plus tu n'utilise d4 que pour faire ton test, c'st pas un peu du gachit ?

Encore si il falait tester avec une valeur bien précise (42 par ex) mais non la c'est zero, donc ton cmp est un peu inutile et lent

et pourquoi pas un tst.s d0 ?

D'accord pour le tst %d0, mais pourquoi ".s"? C'est ".b", ".w" ou ".l", mais pas ".s".

avec s dans {b,w,l}

ok merci pour vos conseil, en tatonnant un peu j'ai trouvé l'erreur : voila le code qui fonctionne :

;input : d0,a0
;output : (a0)
movem.l %d1-%d2,-(%a7)
moveq.l #1,%d1
clr.w %d2
boucle:
add.w #1,%d2
sub.w %d1,%d0
add.w #2,%d1
tst.w %d0
bgt boucle
move.w %d2,(%a0)
movem.l (%a7)+,%d1-%d2

Godzil> Euh, tu veux dire que cmp d0,d4 est plus lent que cmp d0,#0 ?? (au passage, cmp d0,#10 est incorrect, c'est cmp #0,d0 qu'il faut mettre)

Godzil a tort, c'est bien plus efficace (en taille comme en vitesse) de mettre cette constante dans un registre.
Mais bien sûr, tst est encore plus efficace.

en fait si au debut j'avais mis cmp %d0,%d4 c'etait parce que avec tst j'avais aucun resultat
et cmp %d0,#0 et cmp #0,%d0 donnait lieu a des erreurs

C'est ptet plus rapide en "taille" mais en bourrage de registre ça va etre plus rapidement vide

Ben je vois pas en quoi ça serait plus efficace de "corriger" cmp.w d4,d0 en cmp.w #0,d0, alors ? Tout dépend du contexte, mais dans 80% des cas, la pression sur les registres sera suffisamment basse pour éviter d'avoir des opérandes immédiates...