Taille .dol Différente Et Ne Fonctionne Pas !

[iFurby]

Bonjour,

Je débute l'utilisation du devkitpro sur Wii avec la librairie LibWiiSprite et je rencontre quelques difficultés probablement classiques ...

En dehors du fait que j'ai rencontré initialement un problème de compilation résolu par ce topic, j'ai un nouveau problème bien localisé.

Je teste mes .dol avec la chaîne Homebrew et pour être sûr que cela fonctionne, j'ai commencé par compiler les exemples fournis avec la librairie LibWiiSprite. Les compilations fournies avec la librairie s'exécutent bien sur la Wii, par contre celle que j'ai compilées avec les options de compilations livrées en standard ne fonctionnent pas (à la main par make ou via Programmer's Notepad qui fait la même chose de toutes les façons !).

Par exemple le .dol généré pour la démo "invadersHBC" fait 489 Ko (501 216 octets) alors que celui compilé et livré dans la librairie fait 471 Ko (483 264 octets). Donc déjà c'est bizarre (sans tenir compte du fait que j'ai recompilé la librairie), surtout en utilisant le même makefile. J'ai édité rapidement les premiers octets des .dol, dès le début j'ai quelques différences.

Comme je n'ai rien écrit pour le moment, je ne vous met aucun bout de code.

Merci de vos idées et de votre aide.

Furby

[Badablek]

la taille du dol n'a que peu d'importance.

la démo que tu as en standard est probablement compilée avec une vieille version de devkitppc/libogc/libwiisprite. Donc forcement avec des outils plus récents, les résultats ne sont pas identiques. Ce n'est pas ce qui va causer le moindre problème.

quand tu compiles toi-même les exemples, tu n'as aucune erreur de compilation ?

ps : je compile souvent moi-même les homebrews open source, et ils n'ont jamais la même taille au niveua des dol, ça ne m'a pourtant jamais empêché de les lancer avec succès

[iFurby]

la taille du dol n'a que peu d'importance.

la démo que tu as en standard est probablement compilée avec une vieille version de devkitppc/libogc/libwiisprite. Donc forcement avec des outils plus récents, les résultats ne sont pas identiques. Ce n'est pas ce qui va causer le moindre problème.

quand tu compiles toi-même les exemples, tu n'as aucune erreur de compilation ?

ps : je compile souvent moi-même les homebrews open source, et ils n'ont jamais la même taille au niveua des dol, ça ne m'a pourtant jamais empêché de les lancer avec succès

Merci de ta réponse.

Je n'ai aucune erreur de compilation.

J'ai créé 2 répertoires sur ma SD, un avec le boot.dol et les images ... livrées avec la librairie, et un autre où je remplace le boot.dol par celui que j'ai compilé.

Le premier fonctionne sur la Wii pas le second.

C:\devkitPro\examples\wii\libwiisprite\examples\invaders>makemake[1]: `/c/devkitPro/examples/wii/libwiisprite/examples/invaders/invaders.dol' is up to date.C:\devkitPro\examples\wii\libwiisprite\examples\invaders>make cleanclean ...C:\devkitPro\examples\wii\libwiisprite\examples\invaders>makebullet.cppenemy.cppengine.cppentity.cppgame.cppintro.cppmain.cppmenu.cppship.cpptitle.cpplinking ... invaders.elfoutput ... invaders.dolC:\devkitPro\examples\wii\libwiisprite\examples\invaders>

[Badablek]

ça te fait un coredump avec ta version compilée ???

j'avais ce souci sur WiiDoom...pas d'erreur de compilation (bon, plein de warning, mais normal ça) et ça me plantait la console.

en repassant à une version plus ancienne d'une certaine librairie, tout rentrait dans l'ordre.

c'est ça qui est lourd avec ces outils de dév', c'est réglé pour une version bien précise, puis quand y'a une MAJ, ça te plante tout.

[iFurby]

ça te fait un coredump avec ta version compilée ???

Un coredump c'est un plantage avec affichage du code hexa et des registres en question?

Quand je lance le programme sur homebrew, il se passe 5 secondes et on revient au menu homebrew.

Je vais prendre une version de la librairie un peu plus ancienne pour voir.

Modifié le 7 février 2009 par iFurby

[iFurby]

Bon bah c'est pas aujourd'hui que ça va marcher ... http://wiibrew.org n'est plus disponible et je n'arrive pas à récupérer les sources des versions antérieures.

Je vais tenter la compilation d'un programme qui en fait le minimum.

Au fait, pas facile de développer quand même si on est obligé de concevoir et tester directement sur la Wii sans pouvoir débugger au passage ? Existe-t-il un outil ? (émulateur, débugger)

[iFurby]

#include <wiiuse/wpad.h>#include <wiisprite.h>// libwiisprite uses wsp as it's namespaceusing namespace wsp;int main(int argc, char **argv){	// Create the game window and initalise the VIDEO subsystem	GameWindow gwd;	gwd.InitVideo();		gwd.SetBackground((GXColor){ 255, 255, 255, 255 });	// Initialise Wiimote	WPAD_Init();	for(;;)	{		WPAD_ScanPads();		if(WPAD_ButtonsDown(WPAD_CHAN_0)&WPAD_BUTTON_HOME)			break;		gwd.Flush();	}	return 0;}

Ce bout de code fonctionne parfaitement ... bon ça fait pas grand chose mais au moins le code est bien généré.

Je n'ai plus qu'à essayer de comprendre pourquoi il y a des régressions sur les sources précédents histoire de ne pas être bloqué ultérieurement sur un bug à la noix

[Badablek]

pour debugguer, faut passer par un USB Gecko.

c'est apparement ce qu'utilisent la plupart des dev' Wii. Après y'a peut être moyen avec un emulateur genre Dolphin, si c'est pas un homebrew trop compliqué ou qui utilise des fonctions un peu exotiques.

[iFurby]

Il y a aussi une autre méthode, bien plus intéressante qu'un pote développeur utilise pour toutes ses productions professionnelles.

Le développement est construit autour d'un moteur fait maison (auquel j'avais contribué sur PC), les couches basses sont commutables en mode PC ou Wii.

Du coup tout le développement est fait sur une plate forme PC, la WiiMote est également fonctionnelle a minima (même si elle n'a pas le même rendu que sur la Wii en terme de rapidité).

Un paramètre plus loin, le code est généré pour la Wii !!