devkitPro

I am a member of the Odamex development team. Odamex is a modern cross-platform Doom port with a particular focus on the client/server multiplayer aspect. It is also good for playing single-player. I am currently working on console ports. The bulk of my work so far has been extending our SDL input code so that it can support console controls and joysticks in general on all platforms. The rest of the work has been focused on Xbox porting and that is coming along nicely.

This weekend I installed the Homebrew Channel on my Wii and decided to get my development environment together so I can get to work on the Wii port. I have devKitPro installed. To start I used the latest available builds of libogc and libSDL. I was able to compile examples and launch them with wiiload. I then moved on to my port and I got everything compiled. Odamex is C++ so all of the sources in this project are .cpp and .h. Once I had everything built I attempted to launch the port with wiiload. I got a black screen and my system was locked up. "No problem" is what I thought as I figured I would do some debugging and see where I was getting. I've been through this sort of procedure many many times. Unfortunately, none of the debug I was inserting was getting me anything. I decided to go ahead and just return right at the top of my main() function to make sure that it would return to HBC. That did not work. At that point I decided the problem had to occur before my entry point. I know that with SDL your main function is redefined to SDL_main() and the actual entry point is a main() function within libSDL that you don't have direct access to. So I decided to pull ogc and libSDL from svn and build them to make sure that wasn't the cause. I was able to build both fine and I had no issue building and running example applications with them. It did not make a difference with my app. So I went into the SDL_wii_main.c in the SDL lib and did a return at the top of the main() function that is the actual entry point when using SDL. This still did not make a difference.

Where I am at this point is wiiload successfully transfers the app to the Wii and HBC attempts to start it. It instantly freezes at a black screen. No communication with the Wiimote is possible. I cannot connect to it with gdb. The only thing I can do is get up, turn the Wii off, and then start it back up and into HBC which is a procedure I have performed now about 300 times. I have tried everything I could think of from many arrangements of lib linking order, cflags, debug on and off, ripping out bits of code, putting the app on SD card, etc. I commented out all the code that was dependent on SDL_mixer and completely got SDL_mixer and its dependencies out of the way. Other than that I only use the SDL library along with the standard ogc libs. I don't use SDL_ttf, SDL_Image, SDL_gfx, etc. None of this made any difference. But, if I take the main Wii source file and put it in a project by itself it works.

I have committed the changes to svn as the project does successfully compile. I do this work in a branch called odameXbox. It is publicly accessible and anyone familiar with building Wii applications should have no problem building it if you would like to build it yourself. The url to check out the branch is: http://odamex.net/svn/root/branches/odameXbox

The repository is also viewable through websvn: http://odamex.net/svn/listing.php?repna ... 9e303c7371
The Makefile is here: http://odamex.net/svn/filedetails.php?r ... 2FMakefile
The main Wii source file is here: http://odamex.net/svn/filedetails.php?r ... Fi_wii.cpp
i_main is here: http://odamex.net/svn/filedetails.php?r ... i_main.cpp

The rest of the source is also viewable there.

Any help would be greatly appreciated. I am at a complete loss as to why this is happening. I though it might be a cpp + sdl issue but I took a look at the Super Mario War repository and it is all C++ as well and uses SDL extensively. I didn't see anything special being done in the Makefile or in the source. At this point I am wondering if HBC is actually starting the application at all. I just don't know how to get that information from HBC

Thanks for reading.

Hello, Hyper_Eye!

I'm the author of Q1Rev & Q2Rev. I actually have to admit I haven't really looked at Doom's source code, so I'm not really sure if this applies at all with your team's project. But, considering it's a port of a (in it's origin) DOS project, I think a word of caution is in order here.

As it is configured, right now, in the toolchain, Wii apps have a small stack space. Really small stack space. RIDICULOUSLY small stack space. Not even comparable to what DOS is able to give you, by a long shot. I *know*, because of my involvement with both projects above, that Quake (and Quake II) relied on the platform giving the app LOTS of stack space. I can't stress this strongly enough: you get a REALLY, REALLY small stack on your Wii application. That is, unless you modify your makefile(s) in order to get more stack space. Unfortunately, I don't remember right now how can you do that.

I chose, for the projects above, not to modify the makefile, but to actually *move* all big local variables in functions out of the stack, by basically implementing my own "big stack", with its respective alloc() & dealloc() functions, and being really careful of when to invoke such methods. So far, it has worked like a charm.

Could it be that Doom's source code declares 64 or 256Kb local variables (arrays, for example) inside frequently called functions (for example, in each frame)? It has been my experience that NOT ALL stack / heap corruption issues are appropiately detected by the platform (in the form of showing you a nice register / stack trace screen before shutting down).

Hope you find this useful.

Thank you for your response. That is an interesting bit of information. The Doom engine has a zone memory allocator that gets a big heap with a malloc() when initialized. This doesn't occur until a few other things are done first so I don't think this part can be the issue at this point. But, not all allocated memory belongs to this heap. I will have to look around and see if there is a big chunk of memory that might be grabbed when the application is started. I will report back if I come to any conclusions.