J´ai une petite question technique : comment réaliser un algorithme de rotation de sprites rapide sans utiliser DirectX ou OpenGL ?
J´ai déjà programmé deux trois ébauches mais qui, en raison de l´emploi de fonctions trigonométriques, s´avèrent très lentes.
Y a il un moyen d´être plus rapide et de ne pas passer par des fonctions trigo ?
Je voudrais en fait pouvoir passer un tableau à ma fonction ainsi que la mesure d´un angle et que celle ci me retourne un tableau.
Pour passer de :
11111
10001
10001
10001
11111
à
00100
01010
10001
01010
00100
Avec un angle de PI/4
( Ce n´est que du noir et blanc )

hum ! sans trigo ça parait dur

je te rappelle la formule :

( z´-w) = ( z-w)*e^ia

avec z, z´ et w nombres complexes et a l´angle.

z´ = nouveau point
z = ancien point
w = centre de rotation

tu développes tout ça en nombre réel, pour trouver les 2 composantes de z´.
je te conseille de le faire a l´envers : c´est a dire que tu fixes ton z´ ( un double for sur le z´ pour avoir tous tes points dest) et de la tu retrouves le z associé.

je te conseille de développer tout ça a la main pour y mettre sous forme réelle, puis tu précalcules TOUS les coefficients possibles ( et y´en a) qui ne dépendent pas de z´ a l´extérieur du for.

si tu veux le code, je l´ai déja fait, mais en pascal, dans mon fichier FUNIT.PAS que tu peux trouver dans la procédure ROTATEZ de ma routine FUNIT qui se trouve sur mon site :

http://www.fvirtman.fr.st
rubrique info/prog/FUNIT

Autre solution :

tu raisonne comme OpenGL : c´est a dire tu passes par les nombre réels

tu calcules le nouveau repere de rotation de ton sprite en réel ( donc 2 vecteurs a faire sinus et cos, C pas bien méchant)

puis tu préocèdes vectoriellement : tu as a l´origine :

z(a,b) = centre + a*i + b*j

tu calcules i´ et j´ ( rotation)

et tu trouves :

z´(a,b) = centre + a*i´+b*j´

apres, tu rasterises, et C bon.

suffit de travailler vectoriellement.

ton tableau tu as les coordonnés de ces points.
mutliplie chaque vecteur coordonnée par la matrice de rotation suivant l´axe Z:
formule Y=MX:
Image=MatriceDel´Application*Vecteur

MatriceRotationSuivantZ:
[cos t, -sin t, 0]
[sin t, cos t, 0]
[0,0,1]

et pour aller vite en calculant les sin et les cos tu fait un tableau de 90 valeurs float et tu remplis les valeurs du sinus par exemple.
ensuite pour calculer cos(t) c´est sinus(t-90)
voila !

Si tu trouves que c´est trop lent, pk tu ne precalcule pas tous les sprites?
Je pense pas que tu aies besoin d´une precision de l´ordre du degre pr tes rotations. Tu peux par ex avoir les positions pour des angles allant de 10° en 10° ( ca te fera 36sprite). Tu peux chsoisir de faire ts les 30°....etc
32 ou 16 ce sont de bonnes valeurs, pcq ca te permet d´avoir l´angle 45 ; )

De toute facon, selon la taille de ton sprite, tu vois pas la difference entre une rotation de 45° et une de 46°. Si c´est pour un jeu, essaye de faire des essais, pr voir ce qui convient le mieux. La plupart des anciens jeux 2d en vue de dessus avaient des positions precalculees. Apres, tu peux faire l´interpolation entre 2 positions si tu veux plus de precisions, ca donne des resultats acceptables.

Sinon, + simplement, tu ne calcules que les coordonnes de ton rectangle, tu appliques la rotation, et apres tu lances un algo de remplissage, c´est bcp + rapide que de calculer la position de chq pixel de ton sprite. ( comme opengl fait en gros qd tu mets une texture). Si tu decides d´essayer cette methode, cherche des articles sur la maniere dont on peut realiser le plaquage de texture.

Merci pour vos réponses
Si je ne me sert pas de sprites précalculés, c´est parce que je ne me contente pas seulement de les faire tourner : je les grossis également et en même temps.
Quand à la nécessité de rapidité de la fonction, elle s´explique par la vitesse du processeur qui l´emploie : un motorola 68000 ( j´avais d´ailleurs l´intention de l´écrire en assembleur ) .
Ceci dit, il est vrai qu´en créant une table de valeurs, cela devrait bien fonctionner.
Je travaillait au début avec des coordonnées polaires mais il est vrai que le vecteurs peuvent s´avérer utiles.

Un truc comme OpenGL sait te faire ça tout seul, en se servant de la carte graphique ( car tous ces problemes sont implémentés en dur sur ta carte)

Apres, si tu veux, tu peux te servir d´OpenGL ( ou de DirectX)
Autrement, si tu veux y reprogrammer, il y a peut etre un moyen pour appeler les composants de la carte graphique manuellement, mais perso, je ne sais pas bien faire ça

a mon avis vu le processeur ca sent la Ti-89, voire Ti voyage 200.
donc laisse faire pour DirectX il va pas l´importer dans 2 Mo de mémoire.

de meme pour les pré-calculs de sprite, c pas possible de faire tenir plus de ~50 ko de tableaux dynamiques.

ce que tout le monde fait en general c exactement ce que j´ai dit.

rappel pour ceux qui ont connu ca . ..

Motorola 68000 c la base même de nos chers regrettés Atari . .. A l´"époque" on faisait ca très bien ( rotation de sprites + zoom) en assembleur. D´ailleurs beaucoup de démos ont utilisé ces effets là.
lag-it : cherche donc des infos sur les rotozoom tu devrais trouver ton bonheur ; )

je pense avoir encore quelques sources en asm 68000 mais bon je sais plus où ils sont ; ) peut etre sur des disquettes . .

Merci.
Lightness a vu juste
Mais le jour ou je pourrais utiliser OpenGL sur ma ti n´est pas encore arrivé

Lightness je pense pas que ta methode soit la + optimisee. Il vaut mieux calculer les 4 sommets et faire du remplissage comme si on appliquait une texture, plutot que d´appliquer la transformation pour chaque pixel de l´image.
Opengl fais comme ca, et il vaut mieux je pense faire pareil. Les algos de plaquage de texture sont bien connus, et faciles a trouver.