bon, j'ai fait un peu de recherche et enfait, j'en ai deduis que le rotozoom était en fait une rotation dont on multipliais le produit par un facteur - d'où le zoom -
qqn aurait deja programmer ca ?
Miles Le 14/01/2002 à 16:44 Je pense que si tu prends la matrice de rotation, que tu multiplies les valeurs pas ton facteur de zoom, ça devrait aller.
Ce n'est pas dur. Le rotozoom consiste à appliquer une similitude directe (de rapport r et d'angle q) au sprite. Donc à chaque point de la destination, tu appliques la transformation réciproque, qui lui aussi est une similitude directe (mais de rapport 1/r et d'angle -q). Donc:
1. Tu calcules z=e^(-iq)/r.
2. Pour chaque pixel M(x,y) de l'écran, tu calcules s=z(x+iy) et tu arrondis la partie réelle et la parte imaginaire aux entiers les plus proches pour obtenir l'affixe du pixel source S.
3. Si S est à l'intérieur du sprite, si S est allumé, tu allumes M, si S est éteint, tu éteins (x,y).
Un conseil: travaille en virgule fixe:
- calcule z d'abord en __complex__ float, puis 65536z en __complex__ unsigned long. C'est cette valeur que tu utiliseras dans tout le reste de la routine.
- calcule 65536s en __complex__ unsigned long long, puis ajoute 32768 si tu veux avoir un arrondi exact, puis calcule s en __complex__ unsigned long avec un >>16.
[edit]Edité par Kevin Kofler le 14-01-2002 à 16:57:40[/edit]
En effet, les similitudes directes sont au programme de spécialité en Terminale.
Au fait, j'ai oublié de préciser qu'il fallait retirer les coordonnées du centre de rotation de celles de M et les rajouter à celles de S.
Donc l'algorithme corrigé est:
1. Tu calcules z=e^(-iq)/r.
2. Pour chaque pixel M(x,y) de l'écran, tu calcules (x',y')=(x-xo,y-yo) où o(xo,yo) est l'endroit où le centre de rotation sera affiché, tu calcules s'=z(x'+iy'), tu arrondis la partie réelle et la parte imaginaire aux entiers les plus proches pour obtenir s", puis tu rajoutes xO+iyO, où O(xO,yO) est le centre de rotation, pour obtenir l'affixe s=s"+(xO+iyO) du pixel source S.
3. Si S est à l'intérieur du sprite, si S est allumé, tu allumes M, si S est éteint, tu éteins (x,y).
oué... c clair !
Et puis, 8 sprites en pré-calculé ça prend surement moins de memoire qu'une routine de rotations... et c^plus rapide
PpHd Le 14/01/2002 à 19:56 Si vous faites comme ca, ca va etre lent !
Il faut Brehensamiser tout ca a en mourir !
Si on utilise Bresenham, on perd en précision. Avec les complexes en virgule fixe, c'est probablement plus précis.
Et en virgule fixe, on est loin des 30 secondes que ma rotation en virgule flottante mettait. (C'est de l'ordre de grandeur d'une seconde, peut-être même moins.)
[edit]Edité par Kevin Kofler le 14-01-2002 à 20:29:02[/edit]
comment on brehensamise tout ca en plein ?
Y a deux fesses qui sont sur la plage et l'une dit à l'autre :
"Qu'est ce qu'on fait maintenant ?"
Et l'autre lui répond :
"Ben PROUT !!!"
erf, je vien de te dire ke rv en a fait un...
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960
*** Ne sous-estimez pas la puissance de la Marmotte ***
©
Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina
oué mais a mon age faut repeter ... tu verras ca plus tard
J'ai posté un algorithme de rotation par l'écriture complexe sur le forum, et malgré le fait que ça soit en C, la version en virgule fixe était assez rapide. Je pense donc que le rotozoom par l'écriture complexe doit aussi être passable (sauf qu'il faut utiliser des long longs plutôt que des longs à un moment, mais en assembleur optimisé, ça doit passer). Mais évidemment on n'a pas du 30 fps avec ça.
Zeph Le 15/01/2002 à 08:23 J'arrive avec un peu de retard : Bon alors ct pas megacar, mais un autre jeu. Mais bon j'ai bien vu des rotations. Et puis par exemple il y a celui de RV qui marche très bien & vite (même si il ne fait que certaines tailles de sprites bien définies)
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
je me suis trompé, c un sprite de 2^n de coté, car tout se joue au moment du décalage logique vers la droite (car c ce qu'il faut faire sans flottants, passer de grand à petit)
Dans mon algorithme de rotation, rajouter le zoom ne changerait pas grand chose. Il faut juste prévoir des nombres de taille plus grande pour avoir la place pour un facteur >1. Sinon, le facteur de zoom s'intègre directement dans le facteur complexe pour la rotation. (Ça serait le facteur r, et la rotation le facteur e^(i theta).) Et le seul endroit où j'utilise des flottants, c'est le calcul du facteur complexe, qui ne fait pas partie de la boucle (mais est effectué avant). Le reste, c'est de la virgule fixe.
c souvent beaucoup plus facile que ce que l'on peut croire, le rotozoom, en fait, c le pur truc bidon
)
), donc je remets ça à après demain, car ce soir rebelotte 
