virgule fixe - Page 2

c en effet la meilleur solution

-

Orion_ a écrit :
xt=(ox/zx)*65536; // Zoom Factor yt=(oy/zy)*65536;

Il faut multiplier avant et diviser après!
typedef unsigned long long u64;
xt=((u64)ox<<16)/zx;
yt=((u64)oy<<16)/zy;

-

Orion_ a écrit :
u64

Oui, il faut 48 bits minimum de précision pour les calculs intérmédiaires.

D'ailleurs, les calculs sur 64 bits sont lents pour la plupart des plateformes (parce qu'elles sont des plateformes 16 ou 32 bits pour la plupart). (En particulier, la division est très lente sous TIGCC. La routine est déjà assez grosse comme ça.) Ce n'est pas aussi lent que les floats, évidemment, mais quand-même.

Tu peux travailler avec de la virgule fixe sur 16 bits si tu veux aller plus vite. (Ça te permet de travailler sur 32 bits pour les calculs intermédiaires lors des multiplications/divisions.)

Y'a une solution intemediare:
xt = (ox*256)/(zx/256);
C'est pas de la magie, mais ca pourrait t'aider (En gros, on tronque lors de la division en nombre 16 bits).

Non seulement ce n'est pas précis (parce que tu tronques le diviseur), mais en plus ça ne marche pas avec ox supérieur à 256*65536 en représentation interne, c'est-à-dire supérieur à 256 en valeur réelle.

PpHd
a écrit : C'est pas de la magie

-

bah ça te sert à quoi, puique tu perds ta précision... ?

-

-

Orion_ a écrit :
parceque la fonction cos de libmath est ultra lente ! je suis definitivement convaincu que tu c pas lire, ou alors tu t'exprime mal.

J'ai très bien compris l'intérêt d'utilier une table précalculée tête de chauve.
Je te demandais pourquoi tu fais le >>8 juste après avoir lu a valeur, puisque tu perds ainsi ta précision...

-

Bah oui, mais tu perds justement ta précision... Tu tronques la partie décimale (précieuse dans un cos...)

-

oui, mais faut faire le décalage pour le resultat final justement ...

Il a besoin d'un entier au final (apres xscale), donc c bon

moi j'avais un probleme avec mes virgules fixes...
comme orion ,j'avais un table des cos/sin precalculee,ke j'avai multiplie par 256(<<8)

je fesais mes calculs...(evidementje fesais pas la division par 256 tout de suite)

mais le probleme, ct dans les calculs,...
faut il multiplier toutes les valeurs par 256 (pour ke ca soit "homogene"??je pense ke oui
et komment on fait kan il y a des additions,lors de la division finale???...enfin c bizarre

-

C'est totalement inutile de faire un <<8 sur un nombre si tu fais une multiplication après...

et le truc ke tu calcul, tu l'a mis en long?

Orion> ta formule n'est pas bien.
fastsqrt te retourne quoi ? Un entier ou un nb à virgule fixe ?

-

oui, mais un long qui contient un entier ou bien un long qui contient un nb décimal ?

-

non.
Pour une addition ou une soustraction, c'est important, mais pas pour une multiplication ou une division

Orion_
a écrit : factor*cos(sqrt(x*x+y*y))/sqrt(x*x+y*y)

(factor*CosT[fastsqrt(x*x+y*y)])/(fastsqrt(x*x+y*y))
Essaie ça plutôt.

Enfin, ça te donnera un nombre à virgule fixe. fais un >>8 sur le résultat pour avoir la partie entière.