Best method for debugging?

Hello guys, I have a quick question that I was hoping you guys could answer for me. I started porting a game that I wrote before in C++ to the wii and I've seem to run into a little snag, and a good debugger seems like it could be really useful right now. From what I was looking at there are several way to debug on the wii(?)
UsbGecko - Id rather not as it seems expensive and isn't supported anymore
There was this link for debugging over network here which I was trying to follow and got really confused :/
there was also this here which seemed really outdated, since it was last updated in 2009
and lastly there is debugging over dolphin which I was trying to do and nothing seemed to work :/

so my question is what is the best and easiest way to debug on the wii, and it would be really appreciated if you could give me a little tutorial on how to get it set up properly :D

P.S. I really like how if you forget to hit the button, it plays the pirate song :D

Good question, I would like to know how other people approach debugging on the Wii, too.

As I don't own a USBGecko, I gave up on Wii runtime debugging. Instead I've separated the code in my projects into platform dependent and platform independent layers. That way I can easily runtime debug the independed parts on PC, while I've written tests and made heavy use of asserts in the other parts while developing.

For diagnosing crashes on the Wii, there's the addr2line tool (http://arikadosblog.blogspot.co.at/2011/01/how-i-debug-wii-homebrew-crashes.html).

I just started using printfs and sleep recently but most of my fatal crashes come from;
- trying to draw polygons in the wrong 3d mode causing a blank or frozen screen.
- accessing array with the wrong index.
- sending the wrong number of verts to GX causing a blank or frozen screen.
- mixing ints and floats in calculations (doesnt really crash but causes weird side effects)

Owen,

the first three points you mentioned are perfect candidates for asserts. I really recommend using separate debug and release builds to catch bugs like these.

Concerning mixing ints and floats: you should set the warnings level of the compiler so it warns you about implicit type conversions. That way you have to do it explicitly and you are always aware of possible side effects.

Unfortunately there's nothing as good as a USB gecko, since anything else (besides flashing the slot led) requires communicating with IOS and due to libogc limitations that isn't possible without using interrupts and other assorted lwip functions.

Thanks for all the info guys! I've managed to solve my problems using some print statements. Too bad I can't use a full debugger without USBgecko, debugging is kinda fun with gdb :P

Also another quick question, Owen said he used sleep, how do you tell the program to sleep on wii? Is there a function for that or do you just do a for loop with the amount of CPU cycles in a second?

@Hazematman I do a while loop while checking the timer and the key presses. I check for key presses so I can quickly skip the points when I don't want to wait for the loop to end.

void engine_sleep() { //little error console
	float wait=1000, atime=0;	
	while(1) {
		game_updatebuttons();
		if(button_bomb_held | button_shoot_held | button_menu_held | button_start_held ) break;
		if( timer( wait, &atime ) ) break;
		//printf(".");
	}
}

void engine_print( const char *t ){
	printf(" %s", t );		
	if(debug) engine_sleep();
}

@antibyte yeah, I am mostly using C for quick builds. I dont want to turn on all the warnings and be slowed up while testing new code.



Edited 1 time(s). Last edit at 06/15/2012 09:47PM by owen.

I got a funny crash today while trying to declare a big array. Instant crash. The wii stopped outputing video, the power light stays green and the disk drive is solid blue. Maybe its getting old :(



Edited 1 time(s). Last edit at 06/16/2012 12:48AM by owen.

Owen,

a separate debug build is just a matter of a macro, an assert function and a compiler switch:

here's the macro:

#ifdef MY_DEBUG
	#define MY_ASSERT(e) \
	(void)((!!(e)) || (MyAssert(#e, __FILE__, __LINE__), 0))
#else
	#define MY_ASSERT(expression)
#endif

the function's declaration:

void MyAssert(const char* pExpression, const char* pFile, int lineNumber);

This is called, whenever the assert hits (i.e. the expression evaluates to false). Then you can print the info (what file at what line the expression was false) to the screen, save it to a log file, prompt for an action, ...

Now in your code you use asserts whenever you want to validate an assumption, e.g.

MY_ASSERT(startIndex+activeIndexCount <= quantity);

The macro is only used if you add -DMY_DEBUG as a compiler switch (i.e. your debug build). Otherwise it's not there, so no slow downs or code bloat in your release build.



Edited 2 time(s). Last edit at 06/19/2012 02:05PM by antibyte.

@antibyte sounds pretty cool. Will test it out with my new big array quad tree.

I also had another type of bug where I would try to access Array[Max+1] and it would change a value in a totally unrelated array in a unrelated piece of code. Only way I realised it was happening was because its effect was shown on screen. Finding it was a tedious task of printf() before and after blocks of code on the screen and waiting until I saw the value change to isolate where the change was happening on the functions involved.

@owen

To catch that out-of-bound access you would have to add an assert every time you access that array. Of course that is impractical and would clutter your code too much. So in C++ that's where operator overloading comes in. When you overload the assignment operator and place the assert there, an out-of-bounds access will never slip through unnoticed again.

In my Wire3D project I don't use plain arrays, but my own template array (similar to STL's vector) instead. Apart from checking bounds in debug builds (i.e. it doesn't sacrifice speed for security), it also does automatic resizing of the array, if desired. It's not only conveniant, it also helped me to catch bugs early without having to go through the hassle you described.

I create a server socket on wii, connect to it from my pc with telnet and then send trace messages in my program. Keeps my wii output clean at least:)

I'm too lazy for all that, do most my debugging via Dolphin emulator, printf's are sent via the log window.

The Emulator is good at finding hardware programming type bugs that don't show up on the wii straight away, plus you can turn on fancy display features to help your developement.

Thinking of adding a special mode that uses the SMB network, same aim as DRS_ but you can also load files on demand while developing from network rather than SD.

True, I use dolphin too, but try to run this in Dolphin at real Wii speed:)
TenebraeGX

It won't even reach half the framerate on my i7 2860 with SLI and 16GB. Loading the game is even slower. Guess it depends on how much time you have spare:) But Dolphin was very usefull for getting the initial porting stuff done.

In my case, Dolphin is about as useful as a brick.

I'm using a older version of dolphin, ver3.0
Versions above that will give random wiimote movements running homebrew, anyone one why this is?

Quote
Extrems
In my case, Dolphin is about as useful as a brick.

Sounds interesting, what are you brewing?

Quote
Titmouse
ersions above that will give random wiimote movements running homebrew

In my case the mote doesn't work at all in the emu. At least, the buttons don't.