Debugger à travers gint_world_switch ... ou comment transpirer sans faire de sport :D
Posté le 02/05/2022 19:05
Alors voilà, par une belle journée ensoleillée, l'idée est venu de convertir la SDL_image pour la prizm, cool, mais pas simple... et surtout ça ne marche pas comme prévu (voir pas du tout en fait), et il faut désormais comprendre pourquoi chaque morceau pris individuellement (zlib, libpng, libSDL) fonctionne, mais une fois assemblé, niet, nada ketchi, bref ... rien sur l'écran !!!
Oh, séance de débogage pour comprendre ce qui se passe !!! Euh, oui, mais, pas de dprint (car pas de dupdate) car on est dans les fonctions entrée sorties dans les fichiers, donc encapsulé dans un gint_world_switch ... bref, pénible à souhait.
Donc l'idée : créer une fonction dans la libSDL qui va logger dans un fichier, sachant que l'Addin de test appelle à la fois la libSDL_image et la libSDL et que la libSDL_image appelle la libSDL, lui offrant les fonctions de base. Donc si je me mets dans la libSDL, a priori je fais d'une pierre deux coups (en fait trois) et je saurais logger tout ce qui se passe dans l'Adddin, la libSDL et la libSDL_image.
donc je commence par créer une fonction dans le header principal de la SDL et un fichier source :
dans SDL.h
extern DECLSPEC void SDLCALL cSDL_LogToFile(const char *fmt, ... );
et dans SDL.c
#include <gint/gint.h>
#include <stdarg.h>
#include <stdio.h>
void cSDL_LogToFile(const char *fmt, ... )
{
FILE * fp = fopen( "OutLog.txt", "a" );
if (fp==NULL) return;
va_list args;
va_start( args, fmt );
fprintf( fp, fmt, args );
fprintf( fp, "\n");
va_end( args );
fclose( fp );
}
Je recompile la libSDL, tout va bien (c'est pas trop sauvage, donc tout roule).
désormais l'Addin
je mets seulement une portion de code, et vire ce qui n'est pas important
#include <gint/gint.h>
#include <SDL/SDL.h>
void testfunc2( int temp ) {
cSDL_LogToFile( "Hello ceci est un troisième test dans une fonction interne avec parametre : ici temp = %d.", temp );
}
void testfunc(void) {
cSDL_LogToFile( "Hello ceci est un autre test dans une fonction interne sans parametre." );
testfunc2( 25 );
}
int main(void){
...
gint_world_switch( GINT_CALL( cSDL_LogToFile, "Hello ceci est un test dans un GWS isolé" ) ); // test direct dans un giint_world_switch car on trippote dans les fichiers
gint_world_switch( GINT_CALL( testfunc ) ); // test via une fonction (qui fera un appel à une sous fonction)
...
Donc en terme de résultat je m'attends à obtenir un fichier "OutLog.txt" contenant ceci
Hello ceci est un test dans un GWS isolé
Hello ceci est un autre test dans une fonction interne sans paramètre.
Hello ceci est un troisième test dans une fonction interne avec paramètre : ici temp = 25.
mais j'obtiens
Hello ceci est un test dans un GWS isolé
Hello ceci est un autre test dans une fonction interne sans paramètre.
Hello ceci est un troisième test dans une fonction interne avec paramètre : ici temp = -1944191212.
Et la question : pourquoi mon call à testfunc2( 25 ), où temp vaut 25 donc devient ce -1944191212 ?
Ça sent l’adresse mémoire plutôt que le contenu de la variable cette histoire.
Citer : Posté le 02/05/2022 19:10 | #
Pour info, j'ai bien dit que tu pouvais afficher, juste sans le DMA :
r61524_display(gint_vram, 0, DHEIGHT, R61524_CPU);
Pour ce qui est de ton code :
Pour passer les arguments en paramètre via une va_list c'est vfprintf(). Malheureusement la nature non typée des arguments variadiques en C fait que le code ci-dessus compile sans erreur.
Ce problème devient évident si tu regardes ce que la valeur vaut :
0x8c1dff14
Et pouf c'est dans la RAM, la pile pour être exact (c'est l'adresse où sont stockés les éléments de ta va_list).
Citer : Posté le 02/05/2022 19:19 | #
Cool, merci ça marche
la subtilité des 25000 versions de printf ...
OK, donc avec r61524_display(gint_vram, 0, DHEIGHT, R61524_CPU); on passe pas par le DMA, pour raffrachir l'écran c'est ça ?
c'est un "dupdate()" dans DMA en quelque sorte ?
Citer : Posté le 02/05/2022 19:21 | #
Yup ! Manipuler l'écran hors d'un world switch c'est safe. Seule l'utilisation du DMA pour la copie peut poser un problème. Si tu regardes le code de dupdate() c'est essentiellement juste ça avec R61524_DMA ; si on le fait avec le CPU ça passe tranquillou.
Citer : Posté le 02/05/2022 19:43 | #
Ok je connaissais pas cette option
donc je peux faire la petite soeur cSDL_LogToScreen()
et utiliser ça
Merci bcp