Fei 2024-01-30 at 01:07pm Alors là...
Faudrait demander à Alekmaul ou Orion...
makesmc n'a d’intérêt que si ton fxe doit charger des fichiers externes, autrement geepee peut ouvrir directement tes fxe
il existe différentes version de geepee, la dernière n'est pas la plus complète
et la le mec il le pécho par le bras et il lui dit '
le problème de la GP32 c'est que y'avait tellement de bizarrerie comme le freelauncher, gplink etc... que ceux qui n'ont pas connu la gp32 à l'époque, n'ont aucune idée de comment ça fonctionne, et que y'a plus aucun outil qui marche sur les ordi récent
j'ai eu une question aussi d'un gars récemment qui avais choppé une gp32 avec firmware coréen, et impossible pour lui de lancer un homebrew vu que il avais pas le freelauncher ...
pareil, j'ai jamais réussi a faire fonctionner le SDK officiel avec devkitpro ...
Donc si je resume :
Il faut utiliser la lib et l'env de dev original de gamepark et pas celui de devkitpro pour que ca fonctionne ? (du moins sur geepee32)
Une organisation specifique est requise au niveau du SMC ?
avec :
un repertoire GAME et dedans le free launcher ? (c'est quoi free launcher c'est un fxe ?)
un repertoire GPMM avec le fxe du jeu et les sous repertoires ou fichiers a charger le cas échéant ?
regarde l'archive smcMaker
le firmware originel ne permet que de lancer des jeux "commerciaux", chiffrés pour une console ou pour une smc,
les .gxe qui sont dans le répertoire "game"
free launcher est donc un .gxe, qui lance des .fxe, exécutables non chiffrés se trouvant dans gpmm
_ - _ - _
devkitpro utilise gcc, le lien que j'ai mis est un port antérieur du nécessaire, utilisant gcc
mis à part trouver un fix logiciel pour donner à geepee ce qu'il attend il faudrait init la console dans ton code via la lib originelle, ensuite le reste du sdk de mirko devrait pouvoir fonctionner normalement, éventuellement utiliser aussi le flip d'ecran originel, possible que geepee intercepte les appels au "bios" pour l'init et flip d'écran, mirko ayant un code original l'ému s'en bat lec
et la le mec il le pécho par le bras et il lui dit '
Bon on va pas se mentir , ce serait qd meme mieux si on pouvait utiliser devkitpro plutot que minigp32..
Je ne comprends pas pkoi les executables générés par devkitpro ne se lancent ni sous Mame , ni sous geepee32...
C'est une incompatibilté avec le bios ?
Bon après quelques tests de lecture de fichiers ca ne semble pas vouloir bien se passer , je me retrouve pour GpFileGetSize(...) et GpFileOpen(..) avec l'erreur 0xb : ERR_INVALID_PARAM
extrait du code degeu en question :
//...
GpFatInit();
GpRelativePathGet(path);
sprintf(filename,"%sarrows.spr",path);
strcpy(myString, filename);
if (GpFatInitialized() == SM_OK) {
strcpy(myString, "FAT INIT");
}
if (GpSMCDetected() == SM_OK) {
strcpy(myString, "SMC DETECT");
}
if (1/*(err = GpFileGetSize(filename, &size)) == SM_OK*/) {
strcpy(myString, "SIZE");
if ((err = GpFileOpen(filename, OPEN_R, &handle)) == SM_OK) {
strcpy(myString, "OPENED");
if (GpFileRead(handle, buf, 4, &readCount) == SM_OK) {
strcpy(myString, "READ");
}
GpFileClose(handle);
}
else {
sprintf(myString, "Open :error (%x)", err);
}
}
else {
sprintf(myString,"GetSize :error (%x)", err);
}
.....
donc path est vide de toute facon , c'est pe normal ^^
GpFatInitialized et GpSMCDetected() renvoient bien SM_OK
et j'ai bien evidemment ajouté les fichiers que je voulais charger au meme niveau que le .fxe dans le .smc
a savoir -> GP/GPMM
c ptet pas le bon endroit pour les fichiers / data ?
j'ai essayé d'utiliser la lib gamepark avec devkitpro mais il semble y avoir embrouille avec l'eabi de la lib :/
et la le mec il le pécho par le bras et il lui dit '
oue on dirait un soucis avec devkitArm mais ca dépasse mes compétences... dommache..
![[/img]](https://www.yaronet.com/pmag/pubf.gif){kind=link}