Pages: 1 [2] 3 4
|
|
|
Author
|
Topic: Wii Port (Read 22159 times)
|
|
|
JPL
Zebranky food
Offline
Posts: 4
|
|
Re: Wii Port
« Reply #17 on: September 07, 2009, 07:19:53 am » |
|
Hi folks. Just poking my head in to say I haven't given up on this, I'm just busy with other stuff and haven't made much progress. I'll post updates if and when I do. Sorry if anyone's hopes have been dashed!
|
|
|
Logged
|
|
|
|
lakota.james
*Many bubbles*
Offline
Gender:
Posts: 111
|
|
Re: Wii Port
« Reply #18 on: September 21, 2009, 04:36:47 am » |
|
Awesome! I forget about these forums for forever, then come back to discover that someone may make a wii port! I'm so happy. Thanks JPL. Even if you never do get around to it, you still made my day today.
|
|
|
Logged
|
|
|
|
Zared
Zebranky food
Offline
Posts: 11
|
|
Re: Wii Port
« Reply #19 on: October 03, 2009, 05:13:51 pm » |
|
I have a WIi port up and running, you can play SuperMelee or play the main game, but there are major issues still: I had to use the latest revisions (Well nearly so) as 0.6.2 doesn't work period. The reason is it doesn't seem to play nice with SDL Threads as implemented in the Wii SDL port. Since the working version supports pthreads, and I quickly hacked together a wrapper to make the built-in thread library match the pthreads calls, I didn' tbother debugging! There is one issue though, mutex and conditionals and the like are handled using a static array, so I had to really bump up the size of the array for UQM to work, which may be problematic, I'm not sure.
UQM uses mutexes and condition variables for every single data file, so there are thousands in use. Optimally, the best solution would be to rework UQM so that only the graphics thread ever touches the sprites, that way they don't each need their own mutex. The sourcecode comments seem to indicate that de-threading UQM is on the to-do list somewhere But it shouldn't be too inefficient.
The second problem is that load times are incredibly slow. It takes minutes just to get to the title screen. I've tried bumping up the buffer sizes, but this does not help at all! SD card and USB seem about the same amount of awful. I am not sure what the trouble is. If i use raw data files, it's incredibly slow. If I use zip to make SVN data files, its faster, but still frustratingly bad. I wonder if it's because every time it loads an image, it's allocating mutexes and condition variables for it. Since its just a static array, this is linear in the maximum number of mutexes, so maybe that's why its so slow...sadly, the gekko toolchain provided doesn't seem to support decorating functions so I can do an analysis of where it's spending all of its CPU time!
The third and only critical issue, is memory. After around half an hour of SuperMelee it crashes due to malloc failures. If you play the storyline instead, you can talk to the Ur Quan drone, then the starbase, and when you return with the radioactives, it usually freezes during the second starbase dialog. If not then, it will when you return to Hayes after investigating the moon base. Creep saving allows you to progress further of course, so it's a memory issue, not an issue with the particular dialogs crashing things.
The Wii has two seperate memory spaces, a 24 MB one, and a secondary 64 MB one. LibOGC only mallocs from the 24 MB one. I used a modified version to grab from both chips instead, but that is still not sufficient somehow, even though on Windows or Linux my memory usage never goes above 32 MB! I once again wish that I could do an analysis of what functions are spending the most time, and allocating the most memory! Talk on the devkitpro site indicates that this modification is messy because it fragments easily, and can waste a lot of memory.
The guy who ported to the PSP got it working with the PSP's 32 MB of memory, surely I can get it to work with 88? Apparently not though!
It could also not even be memory related at all, I'm only guessing!
Anyways, UQM supports multiple controller settings, and you can add your own, though they won't show up in the in-game config menu. I have it set up to use the wiimote held sideways, like how the virtual console NES games work. 1/2 for shoot / special (OK/cancel), and you can use +/- to zoom/scroll depending on context. Home button to hyperdrive escape during story mode. You can also plug the nunchuck in and use its stick for steering, A shoot B special, +/- still scroll etc, home still hypers. You can also use the game cube ports, A/B to shoot and cancel, yellow stick to zoom and scroll, normal analog stick OR D-pad for steering/thrusting.
It loads everything from USB://uqm, since I have a nice big USB HDD, hard-coded into UQM. I was considering having it always load the config file from SD://apps/uqm, then that config file can point you to SD or USB, depending on where you have your data files, but UQM doesn't allow your data files to be anywhere but in the same directory that the config file is in, so that needs some reworking I think. Loading from an SD card is equally as slow as loading from USB.
If it wasn't for the memory issue causing crashing, I'd almost be happy with it! I can at least play supermelee with my wife without bad loading issues, it just takes a bit to get to the opening menu!
Oh, that reminds me, problem number four, since UQM has got rid of the boarders around the screen that the 3DO version had...I can't see menus and such near the edges of my screen!
|
|
« Last Edit: October 03, 2009, 05:17:33 pm by Zared »
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
|
Re: Wii Port
« Reply #20 on: October 03, 2009, 06:03:07 pm » |
|
Nice to see another port in the works.
I have a WIi port up and running, you can play SuperMelee or play the main game, but there are major issues still: I had to use the latest revisions (Well nearly so) as 0.6.2 doesn't work period. The reason is it doesn't seem to play nice with SDL Threads as implemented in the Wii SDL port. Could you elaborate on that?
The second problem is that load times are incredibly slow. It takes minutes just to get to the title screen. I've tried bumping up the buffer sizes, but this does not help at all! SD card and USB seem about the same amount of awful. I am not sure what the trouble is. If i use raw data files, it's incredibly slow. If I use zip to make SVN data files, its faster, but still frustratingly bad. There used to be load time problems on systems like this, because of short reads. About a year ago, but after 0.6.2, I added read-ahead buffering, which afaik solved those problems. You said you were using "nearly" the latest revisions. How recent is that "nearly"?
I wonder if it's because every time it loads an image, it's allocating mutexes and condition variables for it. Since its just a static array, this is linear in the maximum number of mutexes, so maybe that's why its so slow...sadly, the gekko toolchain provided doesn't seem to support decorating functions so I can do an analysis of where it's spending all of its CPU time! That sounds like a strange implementation of mutexes. I don't see why allocating a mutex would need to be linear in time.
It loads everything from USB://uqm, since I have a nice big USB HDD, hard-coded into UQM. I was considering having it always load the config file from SD://apps/uqm, then that config file can point you to SD or USB, depending on where you have your data files, but UQM doesn't allow your data files to be anywhere but in the same directory that the config file is in, so that needs some reworking I think. Loading from an SD card is equally as slow as loading from USB. Via the environment variables UQM_CONFIG_DIR, UQM_SAVE_DIR, and UQM_MELEE_DIR, you can fine tune the directory locations.
Oh, that reminds me, problem number four, since UQM has got rid of the boarders around the screen that the 3DO version had...I can't see menus and such near the edges of my screen! The SAFE_X and SAFE_Y defines (see src/sc2code/units.h) are responsible for those borders. But you'll also have to bring back the 3DO graphics to deal with the reduced screen estate.
|
|
|
Logged
|
“When Juffo-Wup is complete when at last there is no Void, no Non when the Creators return then we can finally rest.”
|
|
|
Zared
Zebranky food
Offline
Posts: 11
|
|
Re: Wii Port
« Reply #21 on: October 03, 2009, 10:07:23 pm » |
|
I haven't worked on it since April or May I don't think. Several of the problems have worked themselves out on their own, it appears.
I have a WIi port up and running, you can play SuperMelee or play the main game, but there are major issues still: I had to use the latest revisions (Well nearly so) as 0.6.2 doesn't work period. The reason is it doesn't seem to play nice with SDL Threads as implemented in the Wii SDL port. Could you elaborate on that? Sure, well, with 0.6.2 or SVN using SDL Threads, it launches the main thread, and in the UQM threads calls, where it starts the thread, there was some kind of issue where it would sleep while waiting for the init to be done, but would not pass control away, so it would just hang the system!
Well, on a newer SDL revision, it launches, but randomly segfaults during screen fades, such as when loading, or when opening comms. With pthread it appears fine and dandy still.
I'm using UQM r3115, and it has the file caching stuff for zip files. That wasn't the problem though, apparently the version of libfat I was using is just bad. Somebody linked me to a fork of it that's much better. No more loading issues. Takes only 4 seconds now to go from the homebrew channel to the start menu of UQM.
It also doesn't have the issue with not flushing to the log file properly, so reviewing the logs of the crashes I thought were due to memory, I'm seeing "Unable to initilize mutex blah blah blah", so I guess that 1024 was high enough for it to start up and play, but not enough in the long haul. I've upped it to 2048 mutexes and it seems to work fine now. (For now being the key phrase!)
There's a new bug though! After 10 or so minutes of play in the story mode, the rect it's drawing to seems to break somehow:
Example, big image so I didn't embed it!
I'm not an SDL guy, so I dunno what's up! If anybody's seen this issue outside of the Wii, let me know! If not, I'll assume it's a bug with the Wii SDL.
|
|
|
Logged
|
|
|
|
|
Zared
Zebranky food
Offline
Posts: 11
|
|
Re: Wii Port
« Reply #23 on: October 04, 2009, 08:55:21 am » |
|
That problem is solved now too, seems the SDL Wii guys have been struggling to get fast UpdateRects working in 32 bit color (Wii uses 16 bit color) and I guess in doing so they broke something. I tried reverting to r64, before they started doing that stuff, and it no longer has the "creative" projection of the drawing surface.
So it runs well now, seems stable, at least for an hour of exploring, plus a round of SuperMelee. Kind of surprising, I had given up months ago, and now it works fine with a few library updates!
Sometime soon I'll post the .dol file. Currently it's probably not terribly useful, since its hard coded to load everything from a USB drive. The goal is that you will put your .dol and the config file into whatever directory you like on your SD card, and the config will point to the data files and other important directories, either on your SD or on your USB device, which is how homebrew is supposed to work! It looks like this isn't hard, I just misunderstood some comments in the code I think
I'll also include instructions on getting the right versions of all of the libraries it uses. vorbis/tremor is easy to cross compile and zlib comes with libogc, but you do need the right revisions of libogc (for access to MEM2's 64 MB chip) libfat (for speed) and libSDL (for stability/ability to run at all/not getting that bizzare projection like in my screenshot). And you also need to make some modifications to libOGC itself, due UQM using more mutexes than can be allocated out of the box.
|
|
|
Logged
|
|
|
|
|
Zared
Zebranky food
Offline
Posts: 11
|
|
Re: Wii Port
« Reply #25 on: October 05, 2009, 08:11:57 am » |
|
On the Wiki now
The diff is quite minor. The only change that should have needed making, was the functions to handle the files, since libfat uses device names like Windows drive letters, but they can be multiple characters, not just a single letter. There were a number of other small changes, to get around some bizzare behaviours of the Wii SDL. Like, I have to flip the screen in the main loop, or nothing gets drawn. And I have to put something manually into the command line arguments, because the homebrew browser doesn't pass any, and their version of getopt_long seems to crash if there aren't any arguments!
I think every change I made is wrapped in #ifdef though.
I didn't alter the build script. The script ran fine, minus having the correct parameters for the compiler so it would actually run on a Wii, but I just added them myself to build.vars when it was done. When it compiled but didn't link, I put the right includes and libs in there until it linked, and didn't think to go back and put those settings into the script...
|
|
|
Logged
|
|
|
|
|
Zared
Zebranky food
Offline
Posts: 11
|
|
Re: Wii Port
« Reply #27 on: October 05, 2009, 10:45:52 pm » |
|
My mistake, I remembered incorrectly! There isn't a system getopt_long(), so I did use the one included. Since I was always using a logfile in the parameters before, I never noticed until I was setting it up on the SD card (instead of loading the binary over wifi). I've got no idea where exactly the crash happens, other than it's in the command line processing stuff somewhere or other. When I get home I'll try getting my remote debugger working again to see exactly where the crash is.
|
|
|
Logged
|
|
|
|
|
BlackSpathi
Zebranky food
Offline
Posts: 15
|
|
Re: Wii Port
« Reply #29 on: October 21, 2009, 08:37:27 am » |
|
Great job Zared! I just installed it and it seems to works flawlessly!
No problems with the menu, I can see it all.
Now if I can figure out how to create a forwarder channel...
|
|
« Last Edit: October 21, 2009, 08:39:21 am by BlackSpathi »
|
Logged
|
|
|
|
Pages: 1 [2] 3 4
|
|
|
|
|