noob compiling issues

[HunterZ]

There's a note in the SDL headers that you need to extern "C" your main to get it to work with C++, it's basically because it supplies it's own main that does some setup before running the user's main.

I see. Well what I ended up deciding to do in the end was something like this instead of -Dmain=SDL_main:

Code: Select all

#if ((defined(__wii__) || defined(__gamecube)) && !defined(main))
extern "C" int SDL_main(int argc, char **argv)
#else
int main(int argc, char* argv[])
#endif

...which I think ought to work regardless of whether -Dmain=SDL_main is used. It certainly seems to work in the case that it isn't.

I've been attempting to get the SDL wii guys to switch to using the autotools setup for years without much success. Sadly it seems to scare people which is a bit of a shame considering how well it works and how much work I put into the toolchain setup so it's possible to do with devkitPPC & devkitARM.

They're so scared of it that they don't even attempt to provide an sdl-config script to put in .../devkitpro/devkitPPC/bin, and they dismiss out-of-hand and bug reports that make even a tangential mention of autotools/configure.

I find it confusing and intimidating too, but I was able to muddle through.

I'm still not 100% sure how to deal with tools that are meant for the build system when you're cross compiling, often setting --host builds them for the target system instead which might lead to some problems with what you're porting.

I know it's possible because I've seen some GP2X Wiz sources (the Wiz port of POWDER maybe? Possibly convenient since POWDER also has a Wii port) whose build process builds native tools that are used to do (pre)generate .h files or somesuch.

You did inspire me to have a look at using configure && make to build wii SDL though, I've managed to get it to build & install but I'm not yet sure if I've managed to get all the changes that were done for wii. I'm trying to figure out how to get the configure for the tests to ignore build system libraries atm. Right now it's decided to pick up openGL which is a bit annoying.

In addition to --host, you probably need to feed configure your cross-compiling toolchain's include and library paths. This is done either via arguments or via environment variables (configure --help should tell you which it supports).

[WinterMute]

I see. Well what I ended up deciding to do in the end was something like this instead of -Dmain=SDL_main:

Code: Select all

#if ((defined(__wii__) || defined(__gamecube)) && !defined(main))
extern "C" int SDL_main(int argc, char **argv)
#else
int main(int argc, char* argv[])
#endif

...which I think ought to work regardless of whether -Dmain=SDL_main is used. It certainly seems to work in the case that it isn't.

looks reasonable,SDL_main.h does this though

Code: Select all

#ifdef __cplusplus
#define C_LINKAGE	"C"
#else
#define C_LINKAGE
#endif /* __cplusplus */

/** The application's main() function must be called with C linkage,
 *  and should be declared like this:
 *      @code
 *      #ifdef __cplusplus
 *      extern "C"
 *      #endif
 *	int main(int argc, char *argv[])
 *	{
 *	}
 *      @endcode
 */
#define main	SDL_main

/** The prototype for the application's main() function */
extern C_LINKAGE int SDL_main(int argc, char *argv[]);

which looks like it should just work if you include SDL_main.h

They're so scared of it that they don't even attempt to provide an sdl-config script to put in .../devkitpro/devkitPPC/bin, and they dismiss out-of-hand and bug reports that make even a tangential mention of autotools/configure.

I find it confusing and intimidating too, but I was able to muddle through.

Sadly we seem to be in a bit of a minority, there's an awful lot of path of least effort that goes on in the homebrew scene and I can't seem to convince some people that working with an existing autotools setup can actually lead to less work in the end.

I know it's possible because I've seen some GP2X Wiz sources (the Wiz port of POWDER maybe? Possibly convenient since POWDER also has a Wii port) whose build process builds native tools that are used to do (pre)generate .h files or somesuch.

I did see a DS port of POWDER somewhere that needed native tools installed and multiple configure runs to get past that part of the configure which seemed a bit on the awkward side. The process for building cross compilers where you specify a target rather than a host seems a bit more sensible but I don't think I've ever encountered anything else that uses that functionality.

In addition to --host, you probably need to feed configure your cross-compiling toolchain's include and library paths. This is done either via arguments or via environment variables (configure --help should tell you which it supports).

Yeah, I kind of figured that out a while ago when I started getting the toolchain set up to work with autotools without too much fiddling.

I've just uploaded the source for my latest SDL fiddling which uses configure to build - I've included shell scripts for the wii configuration. This needed to delete signal.h from the devkitPPC includes to stop it picking up some functions which aren't supported atm - I should probably kill a few newlib headers that provide unsupported functions but I'm kind of tempted to see if some of them can actually work in some sensible way. I already put quite a bit of work into getting stdio support working like you'd expect. I also needed to build libiconv - the configure I used for this was

Code: Select all

../../../libiconv-1.12/configure --prefix=/opt/devkitpro/portlibs/ppc --host=powerpc-eabi --disable-shared --enable-static

Generally I try to build outside the source directory when possible - it can make things a bit easier if I need to submit patches upstream

The source tarball is at http://sourceforge.net/projects/devkitpro/files/misc/

This setup places the libraries in a different location to the current wii SDL but I'm not yet sure on what options there are to make this all work while maintaining the ability to use different versions for different target systems. Right now devkitPPC supports both wii and gamecube but can potentially be used for any powerpc system which uses a 750cl compatible processor. I have the tests building but any that use filesystem will fail because this doesn't initialise libfat before reaching SDL_main. I think it should but the people who got SDL working chose not to and I need to figure out if there's actually a good reason for that - there may be some potential for problems.

Some of the other SDL libraries will probably compile as is once this version of SDL is installed and should use the same --prefix. Unfortunately it does mean that the other SDL should be removed from the libogc folder to prevent conflicts. The patches made for wii in other SDL support libraries will need to be reviewed.

Ultimately it would be fantastic if we got this massaged into good enough shape to be accepted as a patch into upstream SDL then I can just build binaries and add them to the current collection of portlibs. I'm not really sure about the logistics of this though, I think there were a lot of people involved in wii SDL and I've mostly just used the code they wrote.

[HunterZ]

I see. Well what I ended up deciding to do in the end was something like this instead of -Dmain=SDL_main:

Code: Select all

#if ((defined(__wii__) || defined(__gamecube)) && !defined(main))
extern "C" int SDL_main(int argc, char **argv)
#else
int main(int argc, char* argv[])
#endif

...which I think ought to work regardless of whether -Dmain=SDL_main is used. It certainly seems to work in the case that it isn't.

looks reasonable,SDL_main.h does this though

Code: Select all

#ifdef __cplusplus
#define C_LINKAGE	"C"
#else
#define C_LINKAGE
#endif /* __cplusplus */

/** The application's main() function must be called with C linkage,
 *  and should be declared like this:
 *      @code
 *      #ifdef __cplusplus
 *      extern "C"
 *      #endif
 *	int main(int argc, char *argv[])
 *	{
 *	}
 *      @endcode
 */
#define main	SDL_main

/** The prototype for the application's main() function */
extern C_LINKAGE int SDL_main(int argc, char *argv[]);

which looks like it should just work if you include SDL_main.h

Yeah, I messed with that a bit, but it seems to be as fragile as -Dmain=SDL_main. I don't see the point of using gimmicks like this if I'm already having to #ifdef a bunch of other Wii/GC specific code into the sources anyways.

The good news is I got it to compile the night before last, but didn't have time to test it until last night.

Last night I tried it out and quickly found that I needed to make some modifications to:

• call fatInitDefault()
• possibly use absolute paths (is there a good way to determine the absolute path that the app is being run from, so that users can run from SD or USB without fiddling? It does look like they'll be able to override via meta.xml at least)
• hard-code the SDL video mode to 640x480x16bpp + double buffering (the game defaults to - I think - 640x400x8bpp, which gave me a black/blank screen on my NTSC-U Wii running at 480p)

Once I got that all ironed out, the game actually booted and showed me a first-run configuration screen (exciting!). Of course, I couldn't interact with it because I haven't put in Wii-specific code for the controls, so that's the next step. The game is a side-scrolling 2D platformer that normally uses keyboard to move and mouse to aim and shoot, so I'm planning to try to achieve the same functionality via the Nunchuk and Wiimote respectively.

Any advice on whether I should use WPAD or SDL joystick functions to work with the Wii controller inputs?

In addition to --host, you probably need to feed configure your cross-compiling toolchain's include and library paths. This is done either via arguments or via environment variables (configure --help should tell you which it supports).

Yeah, I kind of figured that out a while ago when I started getting the toolchain set up to work with autotools without too much fiddling.

I've just uploaded the source for my latest SDL fiddling which uses configure to build - I've included shell scripts for the wii configuration. This needed to delete signal.h from the devkitPPC includes to stop it picking up some functions which aren't supported atm - I should probably kill a few newlib headers that provide unsupported functions but I'm kind of tempted to see if some of them can actually work in some sensible way. I already put quite a bit of work into getting stdio support working like you'd expect. I also needed to build libiconv - the configure I used for this was

Code: Select all

../../../libiconv-1.12/configure --prefix=/opt/devkitpro/portlibs/ppc --host=powerpc-eabi --disable-shared --enable-static

Generally I try to build outside the source directory when possible - it can make things a bit easier if I need to submit patches upstream

The source tarball is at http://sourceforge.net/projects/devkitpro/files/misc/

This setup places the libraries in a different location to the current wii SDL but I'm not yet sure on what options there are to make this all work while maintaining the ability to use different versions for different target systems. Right now devkitPPC supports both wii and gamecube but can potentially be used for any powerpc system which uses a 750cl compatible processor. I have the tests building but any that use filesystem will fail because this doesn't initialise libfat before reaching SDL_main. I think it should but the people who got SDL working chose not to and I need to figure out if there's actually a good reason for that - there may be some potential for problems.

I read that calling fatInitDefault() "too many times" after it has already been called and has returned successfully may cause bad things to happen, so it may be that they avoided calling it in SDL_Wii in case someone using it in their project wants to have control over where it gets called.

Some of the other SDL libraries will probably compile as is once this version of SDL is installed and should use the same --prefix. Unfortunately it does mean that the other SDL should be removed from the libogc folder to prevent conflicts. The patches made for wii in other SDL support libraries will need to be reviewed.

I wonder if rebuilding SDL and SDL_mixer in this way will factor out that uintptr_t conflict between SDL-Wii's SDL_config_minimal.h and devkitPPC's stdint.h?

Ultimately it would be fantastic if we got this massaged into good enough shape to be accepted as a patch into upstream SDL then I can just build binaries and add them to the current collection of portlibs. I'm not really sure about the logistics of this though, I think there were a lot of people involved in wii SDL and I've mostly just used the code they wrote.

Yes, that would be great. Unfortunately, though, SDL seems to be in a weird state where 1.2 is in maintenance mode (the latest official version, 1.2.14, was released almost 2 years ago) and 1.3 is extremely rough around the edges; as a result, there may be some upstream resistance to any significant modifications to 1.2.

Also, I'm not sure about the latest source in the SDL-Wii repo, but the pre-built release of SDL-Wii is based on SDL 1.2.13. This means that SDL-Wii may need to at least merge in the SDL 1.2.14 updates before anything can go upstream.

[WinterMute]

[*]possibly use absolute paths (is there a good way to determine the absolute path that the app is being run from, so that users can run from SD or USB without fiddling? It does look like they'll be able to override via meta.xml at least)

Absolute path is held in argv[0] or you can use getcwd after fatInitDefault is called.

Any advice on whether I should use WPAD or SDL joystick functions to work with the Wii controller inputs?

Personally I'd try to use the SDL functions if possible which should help keep things portable for when you or someone else decides to port it to another console :p

I read that calling fatInitDefault() "too many times" after it has already been called and has returned successfully may cause bad things to happen, so it may be that they avoided calling it in SDL_Wii in case someone using it in their project wants to have control over where it gets called.

Well I'd probably tend towards a weak function for filesystem init that can be overridden from user code so it wouldn't prevent taking control if required.

I wonder if rebuilding SDL and SDL_mixer in this way will factor out that uintptr_t conflict between SDL-Wii's SDL_config_minimal.h and devkitPPC's stdint.h?

Absolutely.

Yes, that would be great. Unfortunately, though, SDL seems to be in a weird state where 1.2 is in maintenance mode (the latest official version, 1.2.14, was released almost 2 years ago) and 1.3 is extremely rough around the edges; as a result, there may be some upstream resistance to any significant modifications to 1.2.

Hmm, well I guess we'll have to cross that bridge when we get to it.

Also, I'm not sure about the latest source in the SDL-Wii repo, but the pre-built release of SDL-Wii is based on SDL 1.2.13. This means that SDL-Wii may need to at least merge in the SDL 1.2.14 updates before anything can go upstream.

That's already done, I was working from the 1.2 HEAD in their mercurial repository.

[HunterZ]

I've now got the control code implemented. I almost completely supplanted the game's SDL mouse button and keyboard event handling (via #ifdefs) and wrote a bunch of code to translate the Wiimote and Nunchuck/Classic Controller controls to simulated mouse button and keyboard events.

Unfortunately this still didn't work. I had put my calls to the SDL joystick initialize/open functions in the game's joystick code, but I realized that the joystick code was just a stub (complete with "not implemented" comments) that probably wasn't being called. After moving these to just after the place where SDL_Init() gets called, the controls now work and I can start the game!

Unfortunately (agh!), the game seems to crash dump 0-2 seconds after I use the left analog stick and possibly D-pad (the two things I'm handling in the event handler) on the Classic Controller (haven't tested the Nunchuck yet). I guess I'll need to either find and get working some debugger tools, or else scour my code to try to figure out what's going wrong.

[HunterZ]

Debugger was a no-go (well, I got to the point of being able to trace stack dumps to file names + line numbers, but it didn't really help much). I did get wiiload figured out in the process, though, which is a huge bonus since I was previously moving my USB HDD back and forth between Wii and PC every time I wanted to test a new binary.

After examining the code, I eventually figured out that I could fix the crash by employing an anachronism of the game engine's input handling. Specifically, I need to return a key event type of "spurious" when I decide not to translate an SDL input event into a game engine keypress event (for example: when the joystick is moved from left to even farther left).

I also found that I had transposed up and down in half of my joystick axis up/down/center to up/down/neither key translation logic, which made my character do silly things (like jumping and teleporting uncontrollably). At first I thought it was a deadzone issue, but then I realized that left/right was working just fine.

After playing for a bit, I noticed that the top and bottom of the picture seemed to be cropped. Up to now I had been running the game at 640x480 as a result of various attempts to fix the black screen after setting the video mode, but it turned out that this was not necessary because the real fix was setting a 16bpp mode instead of 8bpp. I returned the game to its original setup of rendering internally at 320x200 and scaling by 2 to display on an SDL screen resolution of 640x400. This seems to work well, with all elements visible on screen and a mouse cursor that is easier to control.

The game is now quite playable. I am currently adding more input translation to allow changing weapons, and possibly pausing/resuming and quitting the game. Once that is done, I should be ready to share it with others for testing. I should probably see if saving/loading works without modifications, and I should probably code up those absolute path checks so that it can run from SD or USB without configuration. Finishing the game would be a good test, too, but I doubt I'll have the patience so I'll probably leave that to others.

I should also update to the game's latest SVN source. It hadn't been touched for 4 months and then they went and made an update the day after I did a checkout!

[HunterZ]

Still working furiously. Tightened up the controls a lot, and added the ability to cycle the active weapon and bring up the main menu (so that you can pause/quit or adjust settings). Tested saving/loading, which works fine.

Decided to use the buttons on the Nunchuk/Classic Controller instead of the stick up/down, which works great 90% of the time because you use them for jumping and activating things. The problem is the 10% of the time you need to use them to climb ladders. Oh well.


Found an issue with handling the joystick axis positions via SDL events instead of polling in combination with limitations of this game engine: because the game's SDL wrapper can only pass one key down or key up event to the core game engine for every SDL event processed, it's possible to wiggle the joystick fast enough that I don't get enough SDL events to translate to key up events. The symptom of this is that the character can get stuck running in a direction even though the stick is centered. I've put in enough logic to make sure that state gets cleared out on any subsequent nudge of the stick, though, so you really have to try to get it to happen now.

Really the SDL event wrapper ought to be rewritten to queue up and fire off multiple game engine events when necessary instead of forcing a 1:1 ratio, but I inherited that code from whoever ported the game to generic SDL and am therefore not inclined to refactor it at this time.


I've also come to believe that the wiimote-controlled mouse cursor is too sensitive. Currently, the game has a lot of voodoo regarding calculation of the cursor position (with weird bit shifting stuff), with the added bonus that I can't figure out how to implement any kind of sensitivity adjustment since it seems to be using the absolute instead of relative position in the event handler. I tried implementing relative position math, but it seems to make the cursor a bit jerky and causes it to get stuck near and/or on the edges of the screen for some reason. I guess I'll have to just live with the stock implementation.


Another issue I'm seeing is that the mouse cursor is garbled on the brightness setup screen, which is the first screen to appear when the game is run. The cursor looks fine on the main menu (looks like an arrow) and in-game (looks like a targeting reticle), so I'm not sure what's going on. I think the game blits the cursor graphic onto the screen since it hides the SDL cursor during startup.


Finally, I noticed that with my Wii running at 480p on a 16:9 TV and SDL running at 640x400, the game is stretched horizontally to fill the physical screen. It would be nice to be able to detect 480p versus 480i and show the game in the correct aspect ratio like real Wii games do, but I'm not sure how to go about that.


To do:

• Implement filesystem path detection
• See if I can get music working by dropping some timidity patches into the game's installation directory
• Maybe investigate the garbled startup cursor and/or widescreen issues

[HunterZ]

WinterMute: I feel bad posting so many consecutive posts, but the edit button times out after a while and you haven't replied for a few days. Oh well, this should be one of the last posts relating to my porting effort! Also, it's been a couple of days since my last post and I've still been working furiously:

I noticed yet another issue with SDL Wii: The stereo sound channels are reversed. I know for sure that it's SDL Wii's fault (or some dependency of it) because it also happens in WiiDoom. I added a Wii-specific workaround to the game's source to reverse the panning value of sound effects.

Next I tackled the garbled mouse cursor. I couldn't find a call to set the cursor graphic prior to the one-time initial call to the brightness setup function, so I added one and it fixed the problem. I can't help but think that this must be a bug in the base SDL port, but I haven't tested it on Linux (or Windows). There's a secondary issue of the cursor leaving slight bits of garbage on the brightness menu, but I don't think anyone will care enough to make it worth investigating.

I was able to get music working quite easily by simply installing Timidity patches via instructions found for other Wii ports of SDL-based games.

I then set out to implement filesystem path detection via argv[0]. I was able to code this up very quickly, but it broke something that took me most of the weekend to figure out how to fix! I was really pulling my hair out on this one. Turns out that not one, but TWO places in the source had a kludge that prepends the data directory path to a filename if the filename string does not begin with '/'. This of course breaks on the Wii because absolute paths start with either "usb:/" or "sd:/" instead of '/'. I found one case straight away because it was near the top of the main game source file (in which main() is defined), but I had no idea that the other case even existed until I jumped through a bunch of hoops:


First, I tried to implement some printf() based logging. This was basically unreadable because the screen would get repainted afterwards, even if I first called SDL_Quit() or de-initialized the SDL video subsystem, and even if I spammed the printf()'s in an endless loop.

I did eventually find a GX hack to return to text mode (whatever that means on the Wii), but it had quirks (like eating some of the printf()'s if I didn't wait a bit first) and my logging didn't seem to be catching the source of the problem anyways.

I then decided to try running the game in Dolphin (the Wii emulator) to see if I could get some quicker feedback from adding logging than I was getting by using wiiload to push the binaries to my real Wii over my home LAN. This took some effort, but it paid off in the end because it helped convince me to dig into the game's source enough to realize that there was a second case where that previously-mentioned kludge was implemented.


Once I got that ironed out, things worked even better than they had been prior to the path detection changes. Specifically, the user's initial brightness setting selection was now saved to the disk and loaded on subsequent runs, preventing the user from being forced to go through that process on every run.

I then cleaned up all of my changes (via ToroiseSVN) and tested to make sure it would work on SD, since I had been testing on USB all along, and there were no issues.

After that, I rounded up the documentation/license files (my favorite was COPYING.WTFPL, which describes the "Do What The F**k You Want To Public License") and wrote up some documentation, then released it by uploading to a new Google Code project and creating the requisite stuff on the Wiibrew.org Wiki: http://wiibrew.org/wiki/Abuse_Wii

Mission accomplished!


My only outstanding question is whether I can easily adjust the picture to not be stretched horizontally when the Wii is in 480p mode. I did see a GX trick, but I wanted to ask here about it first because someone suggested that an easier way may have been added to libogc at some point.

I should also contact the original source maintainer and see if he's interested in merging my port upstream so that it can be included as part of the baseline distribution.

[tueidj]

It's probably a bit late to be mentioning this but if you look at the SDL-wii source code I included in the Corsix-TH source package, it includes a rewritten audio backend (using libaesnd for format/rate conversion and correct channel ordering) and substantial changes to the video backend including a widescreen mode (848x480), hardware palette support and on-demand screen refresh (unlike the old code which constantly redraws the screen).

[HunterZ]

It's probably a bit late to be mentioning this but if you look at the SDL-wii source code I included in the Corsix-TH source package, it includes a rewritten audio backend (using libaesnd for format/rate conversion and correct channel ordering) and substantial changes to the video backend including a widescreen mode (848x480), hardware palette support and on-demand screen refresh (unlike the old code which constantly redraws the screen).

Thanks, I might take a look. Widescreen support is one of the loose ends I still have, and the game originally wanted to set an 8-bit video mode for hardware palette support (which isn't supported by stock SDL-Wii).

The only other outstanding issue I have is that the Wiimote cursor seems overly-sensitive and tends to stick to the screen edges.


Edit: I'm getting the following error trying to compile your sdl-wii source from CorsixTH-wii-src.zip:

Code: Select all

src/audio/wii/SDL_wiiaudio.c: In function 'WIIAUD_OpenAudio':
src/audio/wii/SDL_wiiaudio.c(154) :13: error: 'VOICE_MONO8_UNSIGNED' undeclared (first use in this function)
src/audio/wii/SDL_wiiaudio.c(154) :13: note: each undeclared identifier is reported only once for each function it appears in

I did a 'find /opt/devkitpro | xargs grep VOICE_MONO8_UNSIGNED' and came up empty, other than the offending line in SDL_wiiaudio.c.

Edit 2: Looks like it's something missing from my version of /opt/devkitpro/libogc/include/aesndlib.h which I think is from the latest libogc 1.8.8?

Code: Select all

#define VOICE_MONO8                             0x00000000
#define VOICE_STEREO8                   0x00000001
#define VOICE_MONO16                    0x00000002
#define VOICE_STEREO16                  0x00000003