Posté le 23/04/2023 15:49
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 127 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 23/04/2023 15:59 | #
Je n'ai pas le temps de regarder dans l'immédiat, mais voici quelques éléments :
* Avec -Wl,-Map=map dans les flags de link tu peux savoir dans quelle fonction le crashe se situe (en cherchant PC = 0x304002)
* Vérifie les divisions par zéro et les endroits où tu convertis une valeur numérique en entier pour accéder à un tableau
Citer : Posté le 23/04/2023 16:02 | #
Merci pour le conseil je vais vérifier ça
Citer : Posté le 23/04/2023 17:57 | #
* Avec -Wl,-Map=map dans les flags de link tu peux savoir dans quelle fonction le crashe se situe (en cherchant PC = 0x304002)
Il faut utiliser fxlink ?
Citer : Posté le 23/04/2023 18:06 | #
Non dans ton CMakeLists.txt
il faut mettre un truc du genre:
add_executable(graphcraft ${SOURCES} ${ASSETS} ${ASSETS_${FXSDK_PLATFORM}})
target_compile_options(graphcraft PRIVATE -Wall -Wextra -Os -std=c++20)
target_link_options(graphcraft PRIVATE -Wl,-Map=Build_Addin.map -Wl,--print-memory-usage)
target_link_libraries(graphcraft Gint::Gint -lstdc++)
et tu verras les infos dans un fichier Build_Addin.map dans le répertoire build-cg
Citer : Posté le 23/04/2023 19:19 | #
Je ne trouve pas le PC dans le Build_Addin.map ...
Est ce que l'erreur pourrait venir d'un problème de type ou d'un dépassement de ram ?
Citer : Posté le 23/04/2023 19:29 | #
Il faut chercher le PC le plus proche à l'inférieur (je sais pas si je suis clair ahah)
Citer : Posté le 24/04/2023 09:44 | #
Je ne trouve pas le PC dans le Build_Addin.map ...
Le fichier map ne cite que les adresses de débuts de fonction. Il faut donc chercher (comme l'explique Potter) la fonction qui commence "juste avant" PC. Par exemple, dans cet extrait
0x0000000000308724 _gintctl_gint_usbtrace
.text 0x0000000000308f90 0x340 CMakeFiles/gintctl.dir/src/libs/bfile.c.obj
0x0000000000308f90 _explore_folder
0x0000000000309100 _gintctl_libs_bfile
Un crash avec PC = 308fb2 serait dans la fonction explore_folder.
Note que les adresses en question changent chaque fois que tu modifies le code et recompiles donc il est important de produire le bug et regarder immédiatement. Si tu modifies des choses avant de regarder tu risques de tomber sur une autre fonction, ce qui serait très rageant...
Citer : Posté le 24/04/2023 10:18 | #
J'ai retiré le Bruit de Perlin et ça se lance. Bon, il n'y a plus de rendu pour une raison que j'ignore mais au moins ça se lance
Citer : Posté le 24/04/2023 11:10 | #
Bon, j'ai fix (je pense) les blocs que ne sont pas chargés mais je crash quand il fait le rendu avec la fonction tangente.
avec le code 001042b6
0x00000000003041a8 __Z5sinfp10FixedPoint
0x00000000003041f0 __Z5cosfp10FixedPoint
0x0000000000304238 __Z5tanfp10FixedPoint
.text 0x0000000000304280 0x424 /root/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/libgcc.a(_div_table.o)
0x0000000000304280 ___udivsi3_i4i
0x0000000000304350 ___sdivsi3_i4i
et voici ma fonction :
{
return FixedPoint::from_float(tanf(a.get_float_converted()));
}
Je ne comprend vraiment pas pourquoi il y a tant de problèmes avec mon FixedPoint ...
EDIT : le code complet est sur le git du premier message
Citer : Posté le 24/04/2023 11:18 | #
Est-ce que ce serait pas juste le tanf qui plante ? Il est possible qu'en passant au point fixe tu aies affecté la précision et/ou le résultat d'un calcul et que tu du coup tu appelles tanf() sur une entrée où elle n'est pas définie. N'oublie pas que c'est des fonctions qui sont capricieuses tout ça, c'est à toi de vérifier que tu donnes pas n'importe quoi comme entrée.
Citer : Posté le 24/04/2023 11:37 | #
Il faudrait un moyen de log get_float_converted() ...
Citer : Posté le 24/04/2023 12:04 | #
Je ne pense pas que cela vienne de la fonction tanf() car en la retirant et en la remplacent par juste 1.0f, j'ai toujours le crash au même endroit ...
FixedPoint tanfp(const FixedPoint a)
{
return FixedPoint::from_float(1.0f);
}
Citer : Posté le 24/04/2023 13:05 | #
J'ai fait un test rapide en clonant le dépôt sur la branche optimisations. Moi j'ai un PC très différent (8c203492) qui n'est pas dans la ROM, donc j'ai pas essayé de chercher quelle fonction c'était, j'ai juste fait une recherche binaire à coup de commentaires.
Et je me retrouve sur
normal = Vector_Normalise(normal);
Tu as au moins une face dont le vecteur normal est nul.
Citer : Posté le 24/04/2023 17:03 | #
J'ai rentré manuellement les triangles et j'ai toujours la même erreur à peu prés au même endroit ... Ca vient peut-être d'un calcul mal fait dans ma struct FixedPoint ?
Citer : Posté le 24/04/2023 18:32 | #
Je ne comprend pas parce que le code suivant affiche bien 2 et 3. (j'ai mis " "%d", (int)test2.get_float_converted() " car je ne sais pas comment afficher le float)
FixedPoint test2 = FixedPoint::from_float(3.1f);
dprint(1, 15, C_BLACK, "%d", test1.get_int_converted());
dprint(1, 30, C_BLACK, "%d", (int)test2.get_float_converted());
dupdate();
Citer : Posté le 24/04/2023 19:04 | #
Ta fonction FixedPoint::from_float() n'a clairement pas de souci, regarde ailleurs. Si les normales sont supposées être non nulles retrace le calcule en affichant les valeurs au fur et à mesure. Tu peux utiliser %f si tu l'actives explicitement :
int main() {
__printf_enable_fp();
/* ... */
}
C'est désactivé par défaut parce que ça prend pas mal de place.
Citer : Posté le 25/04/2023 09:41 | #
J'ai rajouté un code pour écrire les valeurs de normal et dés la première itération de la boucle, j'obtiens 0.0 partout ... Ça veut donc dire que mon vecteur "normal" est nul et que Vector_Normalise() qui fait une division par la longueur du vecteur fait une division par zéro. Il ne reste plus qu'à trouver pourquoi on a ce vecteur nul ...
normal = Vector_CrossProduct(line1, line2);
dclear(C_WHITE); // TODO: remove
dprint(1, 1, C_BLACK, "%f", normal.x.get_float_converted()); // TODO: remove
dprint(1, 15, C_BLACK, "%f", normal.y.get_float_converted()); // TODO: remove
dprint(1, 30, C_BLACK, "%f", normal.z.get_float_converted()); // TODO: remove
dupdate(); // TODO: remove
getkey(); // TODO: remove
Citer : Posté le 25/04/2023 11:24 | #
Sauf erreur de calcul, un vecteur normal nul signifie :
- soit que tu calcules le produit de deux vecteurs colinéaires (tu n'aurais pas pris par exemple deux fois le même vecteur ?)
- soit que l'un des vecteurs (ou les deux) est (sont) nul(s) (tu n'aurais pas pris deux fois le même point pour définir un des vecteurs ?)
ce ne sont bien entendu que des pistes.
Citer : Posté le 25/04/2023 11:33 | #
J'ai remonté les erreurs jusqu'à tomber sur l’opérateur multiplication. Je me suis renseigné et effectivement il y a une erreur dans mon code de multiplication. J'imagine aussi qu'il doit y avoir un problème avec la division.
{
return FixedPoint(a.value * b.value);
}
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)