Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Vos tutoriels et astuces


Index du Forum » Vos tutoriels et astuces » Tutoriels d'utilisation de gint (commentaires)
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Tutoriels d'utilisation de gint (commentaires)

Posté le 15/07/2017 13:54

Les tutoriels d'utilisation de gint sont sur ce topic.

Pour garder les tutoriels ensemble dans les posts du topic d'origine (et surtout pas créer un topic par tuto...), je vous propose de poster vos questions/commentaires/etc ici. Merci !


Précédente 1, 2, 3 ··· 10 ··· 15, 16, 17, 18, 19, 20, 21 ··· 24, 25, 26 Suivante
Gladosse Hors ligne Membre Points: 229 Défis: 2 Message

Citer : Posté le 21/11/2021 17:12 | #


pourquoi est-ce que ce bout de code
dline(134, 99, 134, 104, C_BLACK);
dline(134, 99, 139, 99, C_BLACK);

affiche des lignes plus fines que ce bout de code ?
dline(256, 118, 256, 123, C_BLACK);
dline(256, 123, 251, 123, C_BLACK);
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 21/11/2021 20:55 | #


Hmmm je me brise crâne a essayer de comprendre pourquoi cette ligne me renvoie une erreur.
J'aurai bien besoin d'un coup de main

struct Mesh
{
    const Vertex* vertices;
    int vertices_length;
    const Triangle* triangles;
    int triangles_length;
};

Object* current_object = map->object[i];
int a = current_object->mesh->vertices_length;

Terminal a écrit :
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/lib/libsupc++.a(eh_aux_runtime.o): in function ___cxa_bad_cast':
(.text.unlikely.__cxa_bad_cast+0x8): undefined reference to
_abort'
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/lib/libsupc++.a(eh_aux_runtime.o): in function ___cxa_bad_typeid':
(.text.unlikely.__cxa_bad_typeid+0x8): undefined reference to
_abort'
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/lib/libsupc++.a(eh_aux_runtime.o): in function ___cxa_throw_bad_array_new_length':
(.text.unlikely.__cxa_throw_bad_array_new_length+0x8): undefined reference to
_abort'
collect2: erreur: ld a retourné le statut de sortie 1

Merci si quelqu'un saurait me dire la raison de cette erreur de compilation
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 21/11/2021 21:17 | #


L'erreur est un peu obscure, mais en gros GCC a généré un appel à abort(). Ça veut dire qu'il a détecté un bout de code qui est tellement illégal qu'il est certain que ça va se produire (ie. il a réussi à prouver que ton programme fait un truc illégal peu importe ses entrées).

En général ça veut dire que tu déréférences un pointeur nul quelque part. J'ai déjà essayé d'être malin avec ça mais GCC avait toujours raison ; tu peux être sûr qu'li y a un bug quelque part dans ta logique.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 21/11/2021 22:29 | #


Ok, merci pour la piste.
Je saisi pourtant pas pourquoi m'empêche d'écrire ça
int a = current_object->mesh->vertices_length;
debug_pop("ok ok %i", a); // affiche 4
Vertex* vertex = (Vertex*) malloc(a * sizeof(Vertex)); // ça ça marche
Vertex* vertex2 = new Vertex[a] // marche pas;
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 21/11/2021 22:46 | #


Gladosse a écrit :
pourquoi est-ce que ce bout de code
dline(134, 99, 134, 104, C_BLACK);
dline(134, 99, 139, 99, C_BLACK);

affiche des lignes plus fines que ce bout de code ?
dline(256, 118, 256, 123, C_BLACK);
dline(256, 123, 251, 123, C_BLACK);

C'est la même épaisseur pour les deux. Est-ce que tu ne te fais pas avoir par le problème des sous-pixels de couleur qui sont dans l'ordre RGB ?

Ajouté le 21/11/2021 à 22:55 :
Ninestars a écrit :
Ok, merci pour la piste.
Je saisi pourtant pas pourquoi m'empêche d'écrire ça

Nvm en fait c'est évident vu le message :

(...) in function ___cxa_throw_bad_array_new_length': (...)

std::bad_array_new_length

C'est la levée dynamique d'exception au cas où la taille est invalide. Désolé tu n'as pas forcément de bug c'est dans les fonctions throw qu'il y a ces abort. J'ai lu trop vite.

La fxlibc fournit abort() depuis le 29 Mai. Tu dois avoir une version trop vieille, peux-tu recompiler stp ?

Ajouté le 21/11/2021 à 22:56 :
Farhi a écrit :
C'est moi ou on peut pas faire de class sur Gint ?

On peut, Ninestars en fait. Il te faut GCC compilé avec support de g++ mais aussi la lib standard C++, ce qui je l'admets est encore acrobatique pour l'instant : https://gitea.planet-casio.com/Lephenixnoir/sh-elf-gcc#notes-on-building-libstdc-v3

C'est en train de s'améliorer mais pas hyper vite parce que je nage pas mal, je vais pas le cacher.

Ajouté le 21/11/2021 à 22:58 :
Pour info tes erreurs :

/root/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: CMakeFiles/myaddin.dir/src/main.cpp.obj: in function `_main':
main.cpp:(.text.startup+0x84): undefined reference to `__Znaj'
/root/.local/share/giteapc/Lephenixnoir/sh-elf-gcc/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: main.cpp:(.text.startup+0xb4): undefined reference to `__ZdaPv'
collect2: error: ld returned 1 exit status

C'est parce qu'il a pas les opérateur new. Si tu compiles la lib C++ avec les instructions ci-dessus tu peux ajouter -lsupc++ à ton CMakeLists.txt et il les trouvera.

Tu peux faire des classes de base sans la lib techniquement mais tu auras vite des problèmes un peu dans tout les coins, je ne le recommande pas.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 22/11/2021 00:00 | #


Il y a pas de soucis

J'ai actuellement la version 2.31.1 de fixlibc
Avec visiblement un unique changement sur calloc.c
Je mets à jour.
cd /Users/olivier/Documents/CASIO/fxlibc
git pull
cmake -B build-gint -DFXLIBC_TARGET=gint -DCMAKE_TOOLCHAIN_FILE=cmake/toolchain-sh.cmake
make -C build-gint install

Un git version me renvoie toujours 2.31.1 (je m'y prends peut-être mal)
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 22/11/2021 08:13 | #


Oui alors git version te donne ta version du logiciel git, si tu veux la version du dépôt utilise plutôt git describe :

% git describe
1.2.2-2-ge71f986
# Trois parties séparées par des tirets
# Première partie "1.2.2": dernier tag (ie. ta version)
# Deuxième partie "2": nombre de commits depuis ledit tag
# Troisième partie : identifiant du commit actuel

La version 1.1.0 doit donner abort(). Ta méthode de compilation est correcte. Tu es sur quel commit exactement (ie. que tu donne git describe) ?
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 22/11/2021 22:14 | #


J'ai la version 1.2.2

cd /Users/olivier/Documents/CASIO/fxlibc
git describe
>>> 1.2.2
Inikiwi Hors ligne Membre Points: 594 Défis: 8 Message

Citer : Posté le 22/11/2021 22:19 | #


je remarque que le script ld pour gcc est pour les calculatrices sh3 a 6k de ram. dans le script il est écrit que les sh4 en ont 32. je peux remplacer 6 par 32?
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 22/11/2021 22:26 | #


Ninestars a écrit :
J'ai la version 1.2.2

cd /Users/olivier/Documents/CASIO/fxlibc
git describe
>>> 1.2.2

Vérifie que c'est ça qui est installé, fais-lui lister les fichiers objets s'il le faut :

% sh-elf-ar -t $(sh-elf-gcc -print-file-name=libc.a) | grep abort
abort.c.obj

Supprime le dossier de compilation et recompile, vérifie que dans le CMakeLists.txt le fichier est bien là :

% grep abort CMakeLists.txt
  src/libc/stdlib/abort.c

Vérifie que le fichier compilé est bien là :

% find build-gint -name abort.c.obj
build-gint/CMakeFiles/fxlibc.dir/src/libc/stdlib/abort.c.obj

Et que le fichier source est là :

% find src -name abort.c
src/libc/stdlib/abort.c

Ça devrait pas être difficile à trouver cette histoire...

Inikiwi a écrit :
je remarque que le script ld pour gcc est pour les calculatrices sh3 a 6k de ram. dans le script il est écrit que les sh4 en ont 32. je peux remplacer 6 par 32?

Pas vraiment non, d'abord c'est pas 6 kio mais 8 kio sur SH3 ; donc il faudrait en enlever un bout. Ensuite cette zone est gérée un peu différemment sur SH4. La mémoire en plus est disponible via malloc() : utilise ça plutôt.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 23/11/2021 22:46 | #


Ok je vais regarder ça et je te dis merci

Sinon j'ai ajouté
#include <fxlibc/printf.h>
puis
__printf_enable_fp();

Mais un message à la compilation
libc.a(grisu2b_59_56.c.obj): in function _grisu2':
grisu2b_59_56.c:(.text+0x4d4): undefined reference to
_ceil'
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 23/11/2021 22:49 | #


Ah c'est étrange ça. L'algorithme Grisu2 qui est utilisé pour obtenir la représentation décimale des nombres flottants utilise la fonction ceil(). Rien d'inhabituel jusque-là. Elle est fournie par OpenLibm qui est linkée par gint. Est-ce que tu peux essayer avec VERBOSE=1 pour voir si -lopenlibm apparaît dans la commande de link ?
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 23/11/2021 23:07 | #


/Users/olivier/Documents/CASIO/gcc/bin/sh-elf-g++ -nostdlib -Wl,-Map=map -T fx9860g.ld CMakeFiles/Windmill.dir/src/main.cpp.obj CMakeFiles/Windmill.dir/src/windmill_load.cpp.obj CMakeFiles/Windmill.dir/src/windmill_draw.cpp.obj CMakeFiles/Windmill.dir/src/windmill_clip.cpp.obj CMakeFiles/Windmill.dir/src/windmill_transform.cpp.obj CMakeFiles/Windmill.dir/src/windmill_utility.cpp.obj CMakeFiles/Windmill.dir/src/map.cpp.obj CMakeFiles/Windmill.dir/src/scene_map.cpp.obj CMakeFiles/Windmill.dir/src/camera.cpp.obj CMakeFiles/Windmill.dir/src/game.cpp.obj CMakeFiles/Windmill.dir/src/player.cpp.obj CMakeFiles/Windmill.dir/assets-fx/example.png CMakeFiles/Windmill.dir/assets-fx/img/windmill.png -o Windmill  -lgcc /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/libgint-fx.a -lopenlibm -lc -lsupc++ -lgcc
/Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/../../../../sh3eb-elf/bin/ld: /Users/olivier/Documents/CASIO/gcc/lib/gcc/sh3eb-elf/10.2.0/libc.a(grisu2b_59_56.c.obj): in function `_grisu2':
grisu2b_59_56.c:(.text+0x4d4): undefined reference to `_ceil'
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 23/11/2021 23:09 | #


(...) -lopenlibm -lc -lsupc++ -lgcc

L'ordre n'est pas bon. Dans gint il y a ceci :

set_target_properties(Gint::Gint PROPERTIES
  (...)
  INTERFACE_LINK_LIBRARIES "-lc;-lopenlibm;-lgcc"

Ce qui veut dire qu'il doit y avoir une autre dépendance qui inverse l'ordre. Je crois qu'il y a ça dans ton CMakeLists.txt :

target_link_libraries(${PROJECT_NAME} Gint::Gint -lopenlibm -lc -lsupc++)

Retire -lopenlibm -lc ou change l'ordre.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 23/11/2021 23:16 | #


J'ai retiré et ça fonctionne en effet

Hmmm sinon j'ai l'impression d'avoir un truc incohérent dans mon CMakeLists.txt :
set_source_files_properties(src/map.cpp PROPERTIES
  COMPILE_OPTIONS "-Wp,-w;-Wno-missing-field-initializers;-Wno-maybe-uninitialized")
Pour map.cpp se retrouve là ?
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 23/11/2021 23:18 | # | Fichier joint


mon CMakeLists.txt en PJ au cas où
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 23/11/2021 23:19 | #


C'est juste des options spécifiques à ce fichier, parce qu'il y a dedans des constructions qui activent beaucoup de warnings donc je les ai coupés.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 23/11/2021 23:22 | #


Ah ok je comprend la ligne de commande du coup
Pour map.cpp en particulier tu as mis les option de compilation -Wp,-w;-Wno-missing-field-initializers;-Wno-maybe-uninitialized. Bien vu
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 24/11/2021 14:00 | #


Quelques nouvelles par rapport à ce crash que tu avais, Ninestars. J'ai réussi à le réduire à collision(), ie. la boucle principale ne fais pas de draw(), juste un update(), dans lequel il n'y a que player_move(), dans lequel il n'y a que collision().

Je ne sais toujours pas où est le bug mais comme j'ai eu un crash similaire dans une version plus ancienne de gintctl je pense que c'est de mon côté. Je te dirai, cela dit.

Ajouté le 24/11/2021 à 16:47 :
Conformément aux observations originales, c'est bien lié à un timer. Ça ne surprend absolument plus personne à ce point, avec tous les indices qui y menaient. Tu as bien fait de désactiver le tien, malheureusement il reste toujours celui du clavier qui peut à lui tout seul créer le crash.

Pour savoir si c'est le timer ou le clavier le problème j'ai juste laissé le driver clavier allumé avec un timer qui ne fait rien ; comme ça crashe c'est la faute du timer.

J'ai réussi à reproduire en utilisant soit (1) une fonction clavier, ce qui ajoute le driver clavier au g1a et active son timer, ou (2) ton timer avec un callback qui ne fait rien.

Ça ne crashe que si j'utilise un ETMU, donc ça commence à être assez précis.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2462 Défis: 24 Message

Citer : Posté le 24/11/2021 17:33 | #


Excellent, tu as réussi à bien cibler où le bug se produit. C'est déjà une bonne étape de franchie
Lephenixnoir En ligne Administrateur Points: 24563 Défis: 170 Message

Citer : Posté le 24/11/2021 21:49 | #


Le mécanisme qui semble être spécifiquement en cause c'est le système de callback de gint, par lequel durant une interruption on peut s'échapper de l'interruption pour revenir en mode utilisateur pour exécuter du code (par exemple un callback de timer).

Le fait de s'échapper n'est pas le problème ici, c'est juste le fait d'appeler la fonction gérant l'échappement qui cause le crash (même si la fonction ne fait rien). Le soupçon c'est que cette fonction est spéciale, elle est chargée dynamiquement à une adresse déterminée à l'exécution. C'est la seule fonction qui est traitée comme ça sur SH3 (edit : sur SH4 aussi). Il pourrait y avoir une condition spéciale qui interfère avec ce bout de mémoire après un certain temps ou certaines actions.

Ajouté le 25/11/2021 à 19:02 :
Le bug est résolu selon toutes observations. C'est bien le même truc qui causait ton 5×4 = 6912 et ça se produisait que sur SH3 parce que c'est dans un tout petit bout d'assembleur spécifique au SH3 que l'arnaque se trouvait.

Donc quel génie ce Yatis, et sinon dis-moi si tu recroises le problème.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Précédente 1, 2, 3 ··· 10 ··· 15, 16, 17, 18, 19, 20, 21 ··· 24, 25, 26 Suivante

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 90 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