encore une chtite question - Page 26

Martial Demolins
: non, extgraph <prévoit> cette fonction,

"prévoit" au sens de "propose", elle existe déjà (SpriteX8_Get)!

Kevin> les SpriteX8 de extgraph sont très lentes (ce sont les versions C).
Et de toute façon, je pense que c'est impossible de faire un SpriteX8 plus rapide qu'un SpriteX16.

Sasume
: Kevin> les SpriteX8 de extgraph sont très lentes (ce sont les versions C).

Et alors? On a longtemps travaillé avec une ExtGraph entièrement en C et c'était quand-même tenable niveau vitesse. Et je préfère de loin une librairie un peu plus lente qui propose les fonctions dont j'ai besoin à une librairie un peu plus rapide qui ne les propose pas. (Et de plus, je ne veux pas utiliser un kernel.)

On lui répète depuis au moins 3 ans que certains n'ont pas les mêmes ambitions que lui va.

>Et sinon, ça vous est déjà arrivé d'avoir un prog qui tourne nickel avec VTI, et qui crash la calc (même AMS, PreOs, stdlib)?
Oue souvent.
Essaye de debugguer avec db92. C'est pas si chaud avec un peu d'habitude.

Installe toujours la dernière version du package GTK+ pour Windows ( http://gimp-win.sourceforge.net/stable.html ), et tiens toi à jour à chaque nouvelle release de TiEmu (en supposant bien sûr que tu utilises déjà la dernière version).

Faut envoyer un enhancement request sur le forum de la T3, puis laisser discuter les utilisateurs, puis les developpeurs.

>Par contre le débuggueur est magnifique !

N'est-ce pas. Avec Roms, c'est du sur-mesure.

Bah c'est pas tip-top quoi, mais si tu programmes proprement tu ne devrais pas avoir ce genre de problème. Et d'ailleurs quand tu voudras reprendre le code un jour tu seras tout content d'avoir programmé proprement

Euh il le fait peut être si tu arrives à sortir du prog, mais c'est risqué. Et ce serait affreux, et certains en profiteraient pour dire que le kernel incite à programmer salement. Donc à ne pas faire
Sinon je connais bien le problème, et oui, c'est toujours possible de le faire proprement. Ceci dit c'est possible de restaurer a7 que tu avais sauvé au début, mais comme dit avant, logiquement tu ne devrais pas en avoir besoin.

Bah oui, en général (comme en C quoi) on s'arrange pour faire retourner des codes d'erreurs aux fonctins qui échouent, que ce soit en global, par registre, etc.

Martial Demolins
:Tiens au fait, comment faites-vous pour vous en tirer quand vous êtess rendu au deuxième ou troisième niveau d'appel de fonctions, que vous faites une alloc qui ne marche pas? Si on a sauvegardé les registres à chaque nouvelle fonction, il n'est pas du tout évident de restaurer la pile correctement! J'ai pensé à sauvegarder a7 au début du prog principal, et de le restaurer "de force" en quittant, mais est-ce une méthode propre?

exit de TIGCCLIB fonctionne comme ça.

Sinon, tu peux aussi utiliser ER_throw et consortes (ça fonctionne presque comme les exceptions C++ ou Java), ou renvoyer des valeurs d'erreur (NULL, -1 etc.) dans les fonctions en cas d'échec (comme suggéré par Ximoon dans le ./771).

Martial Demolins
:Réflexion soudaine-> ce n'est pas la peine de le faire en kernel en fait, il le fait tout seul non?

Si, Universal OS ne le fait pas.

kernel::exit: Sortie du programme proprement, appel des fonctions enregistrees, liberation des libraries, liberation de la memoire allouee par le programme, ...
Utilisation:

 
  moveq #1,d0
  jmp kernel::exit

Si on utilise des libraries (genre graphlib ou genlib), a ajouter au debut:

 
  lea graphlib::gray2,a0
  jsr kernel::atexit

ou

 
  lea genlib::quit,a0
  jsr kernel::atexit

pour etre vraiment propre.
(ca fonctionne car ces fonctions ne font rien si elles ont deja ete appellees).

PS: Preos 0.70 minimum

Tout ça marche aussi avec le exit et atexit de TIGCCLIB, à condition d'avoir un kernel qui auto-libère la mémoire. Mais c'est déjà moins contraignant que tes trucs qui nécessitent PreOs 0.70 minimum. Sinon, on peut aussi mettre la libération de mémoire en atexit, évidemment.

Essaye de le faire marcher dans une librarie dynamique le exit de tigcc. ^^

C'est vrai que c'est dommage d'imposer PreOS 0.70 mais ça n'est pas un grave problème étant donné que les kernel précédents sont de assez à complètement dépassés.

en même temps, s'il y a de nouvelles features, autant les utiliser

C'est un peu comme si je disais que l'équipe de TIGCC est pénible parce que pour coder un prog compatible TI-89Titanium, l'utilisation de TIGCC 0.95 > b6 s'impose...