The Ur-Quan Masters Discussion Forum

I know i read this being discussed before, but it wasnt really possible yet.  However, there is WiiWare that it could be ported to (not really sure how that works), and a non-hardware hack http://wiibrew.org/index.php (http://wiibrew.org/index.php) that can run homebrew.  I think that this might be even better on the Wii, for melee 1+2 could be used for fire and special, and B for thrust.  The pointer would be good for menus and dialogue (Actually, mouse would be nice in the real version, now that i think about it. Is there any plans for using it?).
I don't have any idea how hard this would be to do, by the way. If it is way out of the question, then tell me, so i wont dream of the day when someone with a Wii and lots of free time port it.  ;D

Well. I'm not a coder at all, but I can tell you a few interesting bits of logistics that would go into this.

1 - The Wii, I believe, runs a form of PowerPC arcitecture. Any relevant port would need to be compatible with that, if I'm correct.

2 - A WiiWare release has... issues. For one, Nintendo limits published games on this medium to either 40 megs or 43 megs. The music and speech alone outweigh that limit, so any 'official published' version on WiiWare would not only be Game-Content-Only, but would cost money. It would also likely have to be okayed by Activision and/or Toys For Bob, as I understand (in fact, one of those companies would be the ones to approach Nintendo about this to begin with). Not only that, it probably would have to be significantly recoded accordingly; I'm 50% confident that UQM cannot be used for this sort of project. WiiWare is commercial distribution via Nintendo. So if 'amateur users' like us were to even try, I'm sure TfB would go "AHEM. Ours. What the heck are you doing trying to make a profit off our property?"

3 - Any homebrew port would be limited to a maximum of 1.9 gigabytes. ...That's not a huge issue. But it will be competing for space on whatever else is on your SD Card. And I'd really try to see what could be done to make it practical for 1 gig SD cards.

4 - Since we'd be running it from the SD card port on the front, the data must load quickly enough for seamless gameplay from said SD card. Is this an actual problem? I don't know.

5 - Need some way to enter text for fleet names. This would require either an 'onscreen keyboard', or players would have to supply their own USB keyboard to the Wii (possible, but the relevant homebrew libraries for this are still in development), or supply their own fleet files made by other ports.


As a result, I feel front-SD would be the way to go, avoiding WiiWare altogether. That said, I do not personally know if this is even feasible, but I would hope it is. The Wii would be an awesome platform for internet Super Melee play due to its wireless gamepads (I'd prefer a Classic Controller, but a Wiimote held NES style works too), and its wireless internet capability also lends itself well to this.

I can definitely say if someone builds it, I'll be there. But my experience as a coder is inadequate to take on this kind of project at present. Still, the above are some of the things that would have to be accounted for. My best guess is that a Wii port would not be immediate, and would be a moderately significant undertaking.

hmmm... didnt know how wiiware worked, thanks.

how big is uqm? i didnt realize size would be an issue.

thanks for the interest, by the way.

The basic content is about 12 MB, the program code a few megabytes at most and the 3DO music 19 MB. The voice data, however, is over 100 MB. Dropping the bit rate of the 3DO audio to 25% would allow you to squeeze everything into 40 MB but the quality loss would be unacceptable. Losing the voices entirely is probably the best option. It makes sense to limit the size of downloaded games to keep transfer times (and server strain) reasonable and allow the user to keep a decent selection of games on the Wii's internal 512 MB Flash.

With SD cards the full content is not a problem; you could even include the 3DO videos on a 1 GB card and have half the space left over.

CPU architecture is not a problem; UQM works fine on PowerPC Macs already. The graphics hardware, CPU and RAM seem to be sufficient. The lack of a keyboard is not really a problem, as text input is only needed to specify a few names here and there; we can remove all that with negligible effect on gameplay.

There are a few homebrew apps (http://wiibrew.org/index.php?title=Homebrew_apps) with similar requirements, so porting UQM should be technically possible. Looking at the SDLMAME port, it seems that all the libraries UQM needs already exist for Wii. Actually finding these libraries is surprisingly difficult, but they do seem to exist.

WiiWare comes with a bunch of weird legal restrictions from Nintendo, so I'd avoid that. Nintendo apparently expects royalties on every WiiWare game :o and generally speaking have a horribly complicated and demanding process for becoming a developer (most of which involves proving you are a major game developer and publisher already!). I also have no idea how their NDAs interact with GPL.

so, if we remove the voices (which some people dont like that much anyway) it would fit easily on a 1gb sd card, and all the librarys are ported already, then what would someone have to so to port it? remove the keyboard and replace with wii remote? and how hard would that be for someone with very little programming skills?

If we remove the voices, UQM fits easily on a 64 MB SD card or in a 40 MB WiiWare download. Even with the voices, you'll have plenty of space left even on a 256 MB card.

Much of the work, I guess, would be setting up a working Wii development environment, ironing out the idiosyncrasies of SDL on the Wii, testing, and sorting out potential performance problems. Someone with Wii homebrew experience should be able to make a decent attempt, but programming skills are likely to be useful if something doesn't work as expected.

As I said, I'd just forget about text entry and use the remote as an old-school gamepad; after all, the rest of the game only needs two digital axes and a few buttons. I imagine the Remote could be used as a pointing device, so any mouse support that is later added to UQM would probably translate into Wii Remote support.

I don't know if it's of much help in finding the relevant libraries (or if people in this thread are already aware of the site), but wiibrew.org may have some of this stuff already. They've also released updated front-SD libraries that drastically improve the load times, addressing my major concern about a port.

Granted, my lack of coding skill means this is about as helpful as me saying "Go get 'er, Ray." Oh well.

I linked to it in my first post ;)

Hi folks.  I'm guessing there hasn't been any further development on a Wii port of UQM?  A google turned up nothing about a port.

I must say, I'm tempted.  Unlike the DS version people were talking about here a while back, the Wii has the horsepower for it, SDL for Wii seems to have matured somewhat - several bits of notable homebrew (http://wiibrew.org/wiki/Category:Homebrew_using_SDL_libraries) use it - it's now shockingly easy to install homebrew on a Wii, and with external SD card storage it would be pretty easy to fit all the UQM content in.

Plus, ScummVM got a wii port, and UQM has always been in my mind the lesser-known, but still totally awesome little sibling.

My programming skill is hovering somewhere around "intermediate", and I'm thinking this might be a good way to fill in some gaps in my experience, plus it's a game I adore and would love to play on a console.  I might hit some spots where I need to call in some real muscle for sorting out platform specific issues.  For starters, I'd have to figure out how to rope together SDL, the UQM codebase and whatever wii specific dev tools you need to get stuff running on it.

So without making any concrete promises, I think I'm interested.  I have a AAA game to help ship first, so I might not be able to really start work on it until this fall.

What do folks here think?  Is this something you'd be interested in playing, testing or contributing to?  Did I miss an already-underway project to do the same?

I know this is a year-old post, but I'd just like to point out that this is not an issue. First, Toys for Bob renounced all their rights to it when they released it under the GPL license. Second, I don't think you can make a profit on it due to the GPL license; I'm not sure if it actually directly forbids making money on it, but the requirement that the source code be released would mean that free versions would probably appear very quickly.

All known ports can be found here: http://wiki.uqm.stack.nl/The_Ur-Quan_Masters (http://wiki.uqm.stack.nl/The_Ur-Quan_Masters).

I'm happy to answer questions you may have about the source, where I can. You may want to hang out on the #sc2 IRC channel on irc.freenode.net, where more of the devs can be found. Note that response times are likely to be slow though.

I think you're missing a crucial point of how copyright works: By releasing something under some license, you give others the permission to use it; you do not renounce any rights.
Furthermore, only the UQM code is released under the GPL; the content (graphics, music, dialogs, etc) are released under the "Creative Commons Attribution-NonCommercial-ShareAlike 2.5 license", which does not grant you commercial exploitation rights. Porting to the Wii is ok, but to make money off it, you need separate permission from TFB.

Okay, so what I said applies to the code alone then. They've renounced their rights to the code, but retain some rights to the content. Fair enough.

They can still license their code (before our modifications) under different licenses, and they can still lease or transfer ownership of that code.
The only thing you might say that they "renounced" is their exclusive rights.

For the record, this port would be a homebrew project; I'd never ever try to do a WiiWare version, or try to make money off this in any other way.  In fact, if I get anywhere with it and TFB want to use that as the basis for a proper WiiWare release, I'd be more than happy just with my name in the credits.  My main aims in this are to increase my programming skills, learn some stuff about the wii internals, and pay tribute to a game I love.

Meep-eep, thanks for offering your knowledge, I may take you up on that.  I'm comfortable with the IRC knowledge base thing too.

Jeez, I feel like I'm already making promises I'll regret.  I just found out today that the project I'm on will be going an extra few months, so it may be a while before I'm able to start work on this in earnest.  First task will be brushing up on makefiles and figuring out how to reconcile the way DevKitProPPC and UQM like to compile.

If DevKitProPPC works uses GCC and binutils, the easiest way would be to create a dir, put in links to gcc (with the name 'gcc') and the various binutils in it, and put that dir in front of your PATH, so these programs get found before their native versions, set the environment variable BUILD_HOST to something like 'WII', and see how far you get with that. Make sure that your compiler can find the include files and libs of the host system (including everything listed in INSTALL); set CFLAGS and LDFLAGS if necessary.
If that fails, you may need to edit set_host_system() in build/unix/config_functions and build/unix/config_proginfo_host.

Thanks for the suggestion!

Is that more of a quick "see if it works" solution?  It seems inevitable that I'll have to modify the UQM build scripts.  Looks like DevKitPro has a set of rules that point towards their versions of gcc et al, so it should be pretty easy to invoke those from the build scripts.  I figure I need to understand that part of it anyway, even if it is more work.

It's partly see-if-it-works. You should add a definition for the platform in those two files anyhow. But the rest of the steps (the gcc/binutils dir, CFLAGS and LDFLAGS) are probably the cleanest way for the final solution as well.

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!

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. :)

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!  :(

Nice to see another port in the works.

Could you elaborate on that?

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"?

That sounds like a strange implementation of mutexes. I don't see why allocating a mutex would need to be linear in time.

Via the environment variables UQM_CONFIG_DIR, UQM_SAVE_DIR, and UQM_MELEE_DIR, you can fine tune the directory locations.

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.

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.

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! (http://i36.photobucket.com/albums/e4/djholtby/HPIM0927.jpg)

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. 

Weird error. My bet is on Wii SDL.

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. 

Any patches which could be included into the main branch?

And feel free to create a page on the Ultronomicon for this port, like we have for Windows CE (http://wiki.uqm.stack.nl/Windows_CE_port).

On the Wiki now (http://wiki.uqm.stack.nl/Wii_Port)

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...

There is a version of getopt_long() included in the source tree. If you undefine HAVE_GETOPT_LONG in your config_unix.h, that one will be used.

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. 

Im having the same issue, how do you fix this so I can see the cut off parts??

Great job Zared! I just installed it and it seems to works flawlessly!  ;D

No problems with the menu, I can see it all.

Now if I can figure out how to create a forwarder channel...

Star Control on my Wii? Hmmm, I wonder what it would look like on my big screen...

I'll definitely try this out when the insurance people replace my remotes for sure (the movers stole my Wii remotes while packing up my house - they even took them out of the plastic 'Wii Condoms' before they did so. Bastards).

Are you able to run the whole Storymode? This would definitely be a great way to convince my girlfriend to play.

Yes, you can run the whole story mode as far as I have played myself.  It's possible that after prolonged playing a memory leak somewhere will make it crash, but I've got no idea.  So, save often.

Additionally, I've uploaded a new binary for those who have TV cutoff issues.
I used SAFE_X = 4, SAFE_Y = 10, as most of my cutoff was happening at the top and bottom of the screen, and that's where the important starsystem/coordinates is too.

It required a new UI file for the Supermelee menu, where I move the quit button up to where the netplay button would be (if the Wii version supported Netplay!)
I found a few bugs with SAFE_X and SAFE_Y while I was at it though!

Basically there were 5 issues with doing this, though I may have missed some other UI problems this has caused:

The Supermelee Quit button, and that doesn't even involve the code to "fix".

Next, the flashy boxes when selecting ships for Melee weren't being offset.  (Easy fix in the code).

Next, Hayes's dialog was too far to the right.  I don't know if it comes up with any other comms screens, but better safe than sorry, I had it shift baseline.x and/or text width, so that it will always leave at least 6 pixels on either side, so you won't have text right to the edge of the SIS.  Messy but I didn't feel like adjusting each individual comms file! ;)
I don't know how to do a similar thing for the y settings, so I'll just hope it never comes up!

Next, it can't fit all 5 save/load boxes on screen at once if SAFE_Y > 0.  I fixed this by having it calculate how many it can fit.

Finally, when text was near the bottom, it was being clipped, even through it was well short of the scrollbar.  And, the conversation review window was likewise being cut short.
It seems to me that their two extents use SIS_SCREEN_WIDTH/HEIGHT.  But, they are using 0,0 as the origin, not SIS_ORG_X/Y.  I added SIS_ORG_Y like I thought it should be, and that fixed it.  But...that code works if SAFE_Y = 0, and by my reasoning it shouldn't, so I dunno what gives!

Here's the diff on those changes

So, I tried this last night for the lulz (i swear it's the first time I've ever used that word and I'll never do it again)...

...and it was awesome seeing it on the giant screen and using the controls once I got them set up the way I wanted them.  Melee was so much more fun than the old keyboard method.  I got the screen fix in place and everything was going along swimmingly for about an hour til I ran into some Ilwrath for the first time and they were so intimidating that they threw me out to the main menu unexpectedly.  Wish I'd saved it within the prior 45 minutes.  :P

Oh well!  Lesson (re)learned!  Has anyone else tried this yet?  Really, I'm wondering if anyone else has had any luck getting the speech pack and remixes installed and working with this...?  I haven't had any success with that part yet and the instructions I've found so far are more than a little cryptic to me.  As lame as some of the voice tracks are, I kinda miss them now.  Plus, I have a theory that if I could get those parts working, I might actually get my fiance interested in it, too.  After going back to the original music and no vox, I have to admit it sounds a little dated now...  :'(

So, can anyone help?

Your fix for screen cut off works great in melee and game, but in the config menu, its still being cut off. No big deal as I can still select the settings.

Otherwise... thank you , great job on this!

Has anyone gotten the voice and music files to work. I followed the instructions "download as tarball" then I proceeded to zip them with winrar and change .zip to .uqm. I placed them in  apps\UQM\content\packages with uqm-0.6.5-content.uqm.
I also turned up the speech volume within the UQM settings. Still no speech. Help!

file names are:
uqm-0.6.5-content.uqm
uqm-0.6.5-voice.uqm
uqm-0.6.5-3domusic.uqm

Oops, I should have been more clear:  You have all the right steps, DEFIANT, but you make a uqm (zip) archive of the files in the tarball, not the tarball itself. 

Make sure when you're re-zipping it, to zip starting from the base folder that comes out of the .tar file. 

You can also just unzip the entire tarball right into the UQM/content directory on the SD card, but this will have the effect of potentially slowing down the loading of the speech files.  That was before the file system cache was working correctly, however, so the difference may be negligible at this point.

If that doesn't work, I've uploaded my version of the file to the same filefront account as the other files

http://www.filefront.com/14662131/uqm-0.6.5-voice.uqm/

Since I was playing using the old school nostalgic .mod files, I don't have the 3DO music pack ready to upload, but I can do that when I get home.

The config menu being cut off, I'm not sure much can be done about that.  I've also noticed that in the build-ship menu, the ships are offset relative to the docking bays.  I can fix that soon.  I tried using a bilinear filter set to 1.9x instead of 2x, so that everything would fit on screen without having to clip things, but it made it look too blurry, and the text in the bar at the top of the screen was completely unreadable. 

As for either black screening, or falling back to the main menu:  I have duplicated this, and I believe it is an issue with running out of mutexes for all of the graphics and/or music files.  If it fails to load a music file, the music just doesn't play, but if it fails to load graphics files, it crashes back to the main menu, or segfaults.  This is an old issue I thought I fixed, but I guess it needs even more memory allocated.  My bad for not testing long enough play times before I uploaded it. 

I'm a bit busy with end-of-term stuff, but I should be able to upload new versions for the cut-off and non-cut-off binaries, fixing the crash issues. 

Got it working now. No problems as far as I can tell.

Thank you for the continued support!

This just takes me back to the first time I played on the 3DO...ahh the nostalgia... ;D

New version up, increased the heap size.  Seems to not do the "crash when you talk to somebody / start a fight" thing anymore.  Did get one crash when changing ships really fast, but I couldn't repeat it. 

Black border version is gone now.  Turns out there's an option with the Wii to change the scale and offset of the image on the screen.  I've added an extra menu in the setup menu to adjust them on the fly.  Put a green border around the background image, so you can tell where the edge of the screen should be.

Nice...good to see this is getting updates.

Is there any chance of getting a forwarder channel made for this? I'd love to be able to launch this from it's own channel instead of from the home brew channel.

I just tried this out last night, and I've got to say that it's pretty awesome to be able to play UQM on my TV!  I do have one request, though.  Maybe it's possible and I'm just missing something, but I feel like I'm unable to play the main game without being able to use the search function on the Starmap.  I'm sure you're busy with other things, but for the next time you update, I think that would be worth putting in there.

Either way, thanks for the port!

I'm not likely to add a forwarder on my own, but there's a WAD maker called "CustomizeMii" that has a plugin called "FowardMii" that can make them.  I just don't want to brick my Wii trying to make it.

As for search, man, I didn't even know they added that!  You just need to define buttons for the "Search" and "Next" actions and it will work just fine, using joystick input for the letters.

Here's my choice on the button.  This will go into your content/menu.key file.  You can also put it into config/override.cfg


If you do that, and are using Wiimote #1 (without the classic controller) then Pressing "Home" will bring up the search, and pressing "Home" subsequent times will act like tab, moving from cluster to cluster, or system to system.  The d-pad or nunchuck will be used to enter letters, just like the old days if you played it on PC using a joystick! 

Same idea if you're using a different controller, just pick a button/buttons, and put it in there.  Just make sure there are no gaps.  That is, don't put in search.3 without having defined search.2

Thanks, worked out great!  I'm really digging this port so far!  It has crashed once on me, but that was when I went to the "quit" option on the main menu.  It could have been my Wii, though, since it sometimes likes to fade to black and never return.

Once again, thanks! :D

Hello

Sorry if this is considered posting in an old topic, but this port is great and I wondered if it's possible to use the music from the uqm-remix-packs with the Wii version? I did some searching on this topic and couldn't find a clear answer. I got the voices to work.

If it's possible could someone please explain how the folders should be arranged.

If it's not possible is that something planned for a future release?

Thank you in advance :)

I need the source code for this port, does anyone have it by chance??

Trying to make a forwarder and having problems with it. Maybe there's something in the source code that could help me??

EDIT:
I'm guessing it has something to do with the entry point? At least from what I gathered. Customizemii makes the channel with the banner and icon perfect.  However, when I launch the game, I get a code dump or a thin, green bar, horizontally across middle of my screen.

OH Zared!! Where art thou? I need help.

Double EDIT:
I found out that it might be the "entry point" but with out the source code I can't fix it.

see *Wii Port Forwarder (http://forum.uqm.stack.nl/index.php?topic=4755.0)* post

Oops, the source was posted in the Ultranomicon page, but I guess since nobody downloaded it filefront deleted it.  I've put it back now though.

Anyways, UQM looks in the current directory for the content, packages, config files, and so on.  So, if whatever forwarder DOL you're using in CustomizeMii isn't setting the working directory to the same thing as the binary location, it will just crash.   (Or, alternately, if you're loading the UQM binary into the channel, it 100% won't be setting the working directory to the correct place, but in that case it's not really a forwarder, just a UQM channel.)

Thank you Zared, much obliged.

EDIT: Still having no luck trying to forward to UQM without having to use "Universal Forwarder" to do so. Zared, is there something you could do, being more familiar with the source code than I? I was searching through it but found no reference to this: http://gbatemp.net/t181011-homebrew-forwarder-iso-s?st=690&p=2509222&#entry2509222

I'm at a loss on what needs to be added or changed to make this work with just a simple forwarder.

I don't know what you want.  That link doesn't mention anything at all about source code to anything.  But, at any rate, that link isn't even for forwarder channels, it's for forwarder ISOs so you can install them on a USB loader like a Wii game.  (USB Loaders are semi-legitimate programs that load disc images from a USB HDD and run them on the Wii).

At any rate, what's the alleged difference between a forwarder and a "universal forwarder"?  A forwarder is just a tiny application that does only one thing:  load another application.  It doesn't have to be complicated, and it shouldn't ever need the target application to be specially compiled.  I'd imagine that a universal forwarder is just one written to load the target's path from a parameter, so you can use the same forwarder program multiple times without needing to recompile it.  That's the preferred way to do it.  I don't see why having to write your own forwarder each time is a better technique.

I guess I'm not understanding then.

When I use customizemii to make a forwarder, it does not work. I get this thin green bar, then the wii reloads back to the channel select screen. I have it pointed to uqm/boot.dol in apps but it will not work. I was thinking it has something to do with the source code.

The reason for the link was spacificly giantprune's post about "look it the makefile for the LDFLAGS. the init=0xblablabla part is the important bit." Where is this in uqm source code? Or is this something completly different than what I'm thinking?

Something about an "entrypoint".?

I was hoping you might know what that meant? I thought it had something to do with the way the forwarder was created. Also, something about the memory it uses to forwared is the same memory that uqm needs to load, so the game crashes.

Maybe it's too much over my head. Making forwarders for other apps has worked out great. So far it's only uqm that has given me any kind of problems.

I don't suppose you'd like to try out the forwarder I made that given me the load problems? Maybe you can see for yourself what It's doing? Let me know and Ill post it.

Can someone update the wii port to 7.0 please? I'm still using it and would like it to be up to date.

Hello everyone,

Im sorry to bump an ancient post but im planning to play some melee games with friends during christmas, but I cant find the files needed to play the game on a Nintendo Wii. The link on the port page doesnt work.

Could someone help me in the right direction, or might even have the files? :)

Thanks a bunch!

I succeeded to install the game through homebrew browser :)