Posté le 23/04/2023 15:49
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 63 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 25/04/2023 12:02 | #
Ah oui attention.
Typiquement tu passes d'une valeur vers sa correspondance en fixed point (FP) en effectuant une multiplication par un multiple de puissance de 2.
par exemple si tu es en FP32 bits et que tu multiplies tout par 2^16 (65536) pour avoir du FP16.16 (c'est le classique).
alors quand tu multiplies deux FP32 ensemble, il faut faire gaffe à 2 choses :
1/ ca peut déborder donc logiquement on passe par un 64bits pour stocker la multiplication
2/ il faut pas oublier de diviser le résultat par 2^16 car sinon ton résultat est faux (car a ET b on été multipliés tous les deux auparavant)
a * b transformé en FP donne (a * b * 65536)
FP(a) * FP(a) transformé en a*65563 * b*65536 --> d'ou le besoin de diviser une fois par 65536
je sais pas si je suis clair
pour la division, idem, mais cette fois faut multiplier (en réalité il faut commencer par multiplier avant de diviser sinon tu perds la précision)
Citer : Posté le 26/04/2023 12:45 | #
Je ne comprend pas car le code suivant me donne -6.30885 avec 34.68 * 23.809 (j'ai choisi les nombres au pifs )...
{
long raw_value = (a.value * b.value);
return FixedPoint(raw_value / PRECISION);
}
Citer : Posté le 26/04/2023 12:56 | #
entre parenthèse, ton choix de PRECISION est étrange ; PRECISION=8192, soit 2^13; &a signifie que tu travailles sur des fixed point en 19:13
19 bits pour représenter la partie entière et 13bits pour la partie décimale. C'est possible, mais peu habituel
essaye ça et dis moi si ça marche:
FixedPoint operator*(const FixedPoint &a, const FixedPoint &b)
{
FixedPoint r;
r.value = a.value * b.value / PRECISION;
return r;
}
Comment crées tu tes Fixed Point a et b
Si je comprends bien tu as une méthode FixedPoint::from_float(), donc tu dois faire un truc du genre
FixedPoint a,b, c;
a.from_float( 23.009 );
b.from_float( 34.064 );
c = a * b;
mais il faut que tu aies aussi surchargé l'opérateur =;
Citer : Posté le 26/04/2023 16:20 | #
Je ne comprend pas car le code suivant me donne -6.30885 avec 34.68 * 23.809 (j'ai choisi les nombres au pifs )...
{
long raw_value = (a.value * b.value);
return FixedPoint(raw_value / PRECISION);
}
Tu as un overflow.
Deux problèmes :
- Stocker le résultat dans un long ne veut pas dire que le calcul se fait en long. Pour ça il faut que les *opérandes* soient des long.
- Sur la calto un long c'est la même taille qu'un int, il faut un long long.
Citer : Posté le 26/04/2023 18:22 | #
Tu as un overflow.
J'ai adapté ton code et cela marche !
19 bits pour représenter la partie entière et 13bits pour la partie décimale. C'est possible, mais peu habituel
Oui je sais j'ai juste mis ça en attendant que cela marche. Je l'adapterais en fonction de ce qui marche le mieux âpres .
Citer : Posté le 27/04/2023 17:02 | #
J'ai réussi à faire afficher quelque chose. J'ai (parfois) des formes qui ressemblent à des carrés mais je ne comprend pas vraiment encore pourquoi cela ne marche pas parfaitement...
Citer : Posté le 27/04/2023 20:47 | #
je vois notamment un truc étrange, ca doit pas etre suffisant pour expliquer ton problème mais on va y aller petit à petit
const FixedPoint HALF_SCREEN_HEIGHT = SCREEN_HEIGHT / FixedPoint::from_int(2);
me semble louche et serait a priori a remplacer par
const FixedPoint HALF_SCREEN_HEIGHT = FixedPoint::from_int(SCREEN_HEIGHT / 2);
Citer : Posté le 28/04/2023 17:15 | #
Je ne pense pas qu'il y est de problèmes là car SCREEN_WIDTH et SCREEN_HEIGHT sont déjà des FixedPoint donc je ne pense pas qu'il y a de problèmes de calcul à ce niveau là.
Je viens de commit un fix des operators *= et /= et cela rend le rendu un peu moins bizarre (cela ressemble un peu plus à des cubes et non à des traits sans aucun sens sur l'écran) mais tout est encore déformé et la camera avance par à-coup malgré le fait que le FPS est beaucoup plus rapide (je ne sais pas vraiment comment le décrire). C'est peu-être causé par une grosse perte de précision quelque part mais je dois continuer de chercher ...
Citer : Posté le 28/04/2023 19:15 | #
J'ai ajouté une page qui verifie toutes les opérations et elles sont toutes correctes. Le problème vient donc d'un endroit encore plus dure à trouver ...
Citer : Posté le 29/04/2023 14:00 | #
J'ai réussi à fix les bugs du renderer ! (voir dernier commit) Je dois encore un peu optimiser mais c'est correct pour l'instant. Les cubes sont bien affichés donc aucun problème sur ce point. Par contre, il y a un bug qui fait que le rendu ne se fait pas lorsqu'on appuie sur la touche pour avancer ... (très étrange comme bug ) Je vais essayer de le fix mais si quelqu'un voit d'où cela peut venir, je lui en serais reconnaissant .
EDIT : Je viens aussi de me rendre compte qu'il y a un bug qui fait que les cubes repassent devant la camera en inversé lorsqu'on les dépasse... (c'est peut-être lié à la disparition du rendu ...)