The Ur-Quan Masters Discussion Forum

Hi all, new forum member here...

Anyway, I recently posted the idea of doing a port of SC2 to the Nintendo DS (See this (http://forum.gbadev.org/viewtopic.php?t=10808&postdays=0&postorder=asc&start=15) thread for more...) at GBADev.

The idea of doing an UQM port seemed feasible mainly because:
1: SDL has been ported (In part at least) to the NDS
2: The UQM source code is available

Now, having taken a look at the Wiki I can see that doing a direct port of UQM to the DS would not be feasible. The minimum requirements seem a little too high, especially in terms of memory.

So, my question would be, do you guys think that creating what essentially amounts to a data-file compatible clone using the UQM source as a reference is:
A) Do-able
B) Do-able in terms of time

How complex is the UQM source? Are many elements of the single-player game hard-coded?

Finally, just to make sure, do you guys think it would be possible to do a more direct port of UQM to the DS by engaging in some pretty drastic chopping when it comes to game data? By this I mean cutting out pretty much everything that wasn't in the PC version, not to mention doing away with most of the extras added along the way?

My feeling is that a UQM-based clone is very much possible, but a port of UQM itself is probably not feasible...

Anyway, I'd like to here what you guys think about this...

If you're seriously considering attempting such a port, I'll post an extensive reply later.

The source is... complex. Most of the adventure game logic is right there in the C code.

Most of the libraries UQM needs seem to be available on GPF's development site (http://gpf.dcemu.co.uk/ndsSDL.shtml).

For starters, forget about the 3DO music, videos, and remixes. You'd need about half a GB of space for all that, and I don't think the DS CPUs could stand the strain of unpacking all this very well. The main content package is about 12 MB, which should easily fit on a Flash memory card.

Even with only the PC content, I'm mildly concerned about CPU power; how much is needed depends almost entirely on how fast the SDL implementation is (the original SC2, after all, runs fine on a 33 MHz 386).

The screen resolution is going to be a problem. UQM assumes a 320x240 screen, and rescaling that to fit the DS screens at 256x192 is going to be inefficient and messy. You'll probably want to re-layout the graphics quite a bit; for example, the status bar on the right can probably be moved to the secondary screen.

Sound/music shouldn't be a problem in theory, but rewriting the sound code to make full use of the DS's audio capabilities (hardware mixing of enough channels to play MODs and a few sound effects, I assume) could be a lot of work.

Controls shouldn't be a problem; the 3DO didn't have many buttons, either.

If I were you, I'd start off trying to get UQM to run with as few modifications as possible, and then start rewriting graphics and sound code for speed as needed. You shouldn't need to touch the actual game logic at all.

Nice to have gotten some replies.

Okay, I suspected anyway that much of the SP game was strongly hard-coded, since that was generally the case with games of that era...

CPU power is potentially an issue, yes. The DS does have some pluses, in that the ARM7 is is mainly used for handling sound, input and the rest while the ARM9 usually handles advanced graphics and game logic. Thus, with intelligent coding CPU power would probably be a beatable problem.

According to the Wiki, however, UQM makes use of threading, something I'm not sure the DS handles too well, if at all. Hence it would seem that some extensive code refactoring would be necessary in order to make the game fit the DS's architecture...

Screen resolution would be a problem initially, but I think that in the long run this would pass, as the entire screen layout would be altered to fit the DS's form factor. For example, Navigation screen could be the entire of the top display, while the bottom screen would contain HUD info, touch-based controls, etc...

I'll probably have a shot at doing a plain re-compile and seeing how that goes a little later this week...

I think the memory usage has gone down since that wiki page was last edited, but 4 MB is still very little. It's going to be hard fitting UQM in that.

CPU speed may also be a problem, but it may not be impossible. The 3D planet view from orbit may have to go, and also planet landing may require changes.

Threading is used, but not extensively. Just for things like blinking selection boxes. So you could do without that.

I don't know whether the DS has floating point support. UQM uses floating point math in a few places, but the original code didn't use it at all. It should be possible to get rid of it, but it will require a bit of work.

Using the original data files will not be possible. The screen dimensions are indeed an obstacle here. I don't know how easy it will be to use two screens. UQM draws stuff on 'contexts', views within the screen. If you include the screen number in that, then many of the (calls to) draw operations could remain unchanged. The changes would mostly be small modifications to the actual drawing routines to take this screen into account, and changing some coordinates for some images.

If you stick to the .mod music and .wav sound files, sound shouldn't be a problem. You may even be able to use the .ogg music if you can delegate the .ogg decoding to the second CPU.

The content in UQM is compressed (though UQM will work with uncompressed data too). On PCs using compressed data speeds things up as the smaller reads from the hard drive wins you more than you lose from having to uncompress that data. On the DS this probably isn't the case, so using uncompressed data would be best. You can still use one-file packages though; the .zip format can contain files stored without compression.
Anyhow, this shouldn't affect gameplay much. There should never be any need to load while the player is in the middle of something, apart from speech files during conversations, and streaming music, which I guess you're going to throw out anyhow.

Making use of the second CPU, if you're not using it for .ogg decompression, is probably going to be tricky. The only other division that makes sense to me is putting the graphics processing in there, but it may not be easy to cleanly split up the code for that.

All in all, this doesn't sound like an easy port, but it doesn't seem impossble.

In this case, you'd probably have unload unused resources (graphics, sounds) to a greater extent that UQM currently does. Could be hard work.

Running at quite a low frame rate is acceptable for the rotating planet (again, think 386). I'm more concerned about, for example, the scrolling planet landing view (which is much larger in UQM than in PC SC2). Again, if SDL can take advantage of the DS graphics hardware, it shouldn't be a problem, but I suspect it will be.

In any case, getting rid of some of the more gratitious multithreading would probably do UQM some good anyway. It's a lot better than it used to be.

I suspect the compiler will just link its own floating point code if the CPU doesn't have floating point. Slow, but the floating point isn't used for anything heavy, so emulating it with integers is acceptable.

The quick and (very) dirty way to handle this would be to change the last-stage blitting code to blit most of the UQM screen to the main screen and the parts that don't fit to the secondary screen (leaving unimportant bits off completely).

Thanks for the added replies, some very useful info here.

The points you guys have raised do confirm my own growing opinion that an SC2 clone reliant on the UQM data files and elements of the UQM source code might be a better approach. It seems that UQM has developed in such a direction that a vanilla port would probably prove diffcult to say the least.

So, the points raised would be:

• Low memory
• Multi-threaded code
• Suitability of SDL DS
• Limited CPU power
• Screen configuration

Okay, I'm going to put up an UQM thread on GBADev in the next few minutes. I'm going to provide a link to this thread from there and detail the various issues, etc raised in this topic. With any luck some interested DS homebrew wizards will post some comments and I can get their take on the problems in question. At this point I'm think an UQM clone would be best, but I'd like to see what the wizards have to say on the topic.

Once that thread's up I'll post a link to it here. Hopefully once I've gotten a good flow of ideas from both sides I can work out the viability of it all and decide where to take things...

EDIT:
Okay, the GBADev forums post for this topic is here... (http://forum.gbadev.org/viewtopic.php?t=11074)

Enjoy, and feel free to drop any thoughts and comments...

The way I see it, the basic game logic is pretty much OK; it's the low-level stuff (resource loader, graphics, sound) that probably needs to be rewritten and the screen layouts changed. Much of this could be left unchanged, too, if SDL for the DS is improved (which would be advantageous for other ports to the DS). The screen layout may be a bit easier than expected; the main game window is 256 pixels wide, for example. Besides, the 3DO version left quite a lot of space around the edges of the screen unused; UQM has been adapted to make use of the additional space. Squishing the layouts vertically to 192 pixels shouldn't be too hard (PC SC2 was 200 pixels high); it's just a matter of checking all the graphics positioning, really.

Personally, I'd keep as much code as possible from UQM; making UQM better at adapting to different resolutions would make other console ports easier, too. It should also make your job easier.

I have to correct the low memory issues you would have. The Standard size of a Dual Screen cartridge can range from 1 to 1.5 Gigabytes, with posibility for 3 Gigabytes. Resident Evil for the DS incorporated the 1 Gigabyte type to fit all the UCG of the original Resident Evil game in in. Infact, there'd be enough space to add extras, like a SC 1 style mode, maybe Wi-Fi conectivity or even different Super Melee modes?

As for running 3D effects from the original Ur-Quan Masters, this could be a problem. You could convert the rotation graphics into .gif files or you could just make less impressive graphics, if Metroid Prime : Hunters can do this, than anyone else can.

Now the most problematic part I can see would be the dual screen, which could be solved easier than first thought, and having the touch screen as a way to steer your vehicle or to select the options in alien dialog would be neat aswell...

See also here (http://uqm.stack.nl/wiki/The_Ur-Quan_Masters_Project_FAQ#Why_are_the_system_requirements_so_high.3F_The_original_game_ran_fine_on_a_386.) for why the system requirements are so much more than the PC's.

Okay, more useful stuff here.

Thanks for the info on the dimensions Novus. That little bit of info is actually very useful.

Also, thanks for the info on why the PC version has much higher requirements meep-eep. That's very useful, because I can see immediately that some of the problems don't apply so much. For example, we don't need to worry about OS overheads at all on the DS, which should be a big plus. Also, Ogg Vorbis is pretty much out of reach entirely (Ogg Vorbis decoding on the DS only barely manages to roll out in real-time, so this is a good drop...)

Neonlare, thanks for the post. Alas, you are confusing the size of DS carts with the actual problem of the DS' memory itself, two different things. Also, you're getting the sizes of DS carts a bit mixed up. The largest available cart (Resident Evil DS) uses a 1gigabit cart, about 128megabytes of data. Larger carts are theoretically possible, though.

However, you also illustrate a useful point. The DS version is not actually constrained in terms of size. At present DS homebrew software is able to access data stored on SD, MiniSD and MicroSD cards with few or no problems. Storage of game data is not actually an issue really...

The 3D effects would be something to look into. However, seeing as the DS has a very powerful 2D subsystem, harnessing that would probably prove better in the long run...

In terms of interface, I've got a pretty good basic plan already scetched out (Check the GBADev post)

Anyway, I'm going to grab the source later tonight and play about with getting it to compile on the DS. Hopefully I can post some results on the weekend...

I had a shower-time insight, thanks to a post by someone on the GBADev thread...

The 3DO is rather more similar to the DS in terms of basic hardware, etc than a desktop. Hence, it follows that attepting to port the original 3DO source code to the DS might actually be easier, quicker and more efficient than doing a port of the UQM source code...

To this end I've emailed Toys For Bob and asked them whether or not it might be possible for them to release an unmodified copy of the 3DO source code...

Hopefully I'll get some good news...

However, the 3DO had a somewhat unusual OS that apparently encouraged insane amounts of multithreading (much of the work on UQM has been about sorting out the resulting mess). I suspect that getting 3DO SC2 to run on the DS would be harder for this reason alone. Furthermore, you'd definitely have to rewrite most of the graphics and sound code in this case; with SDL you'd probably get the graphics running in some fashion at least with less trouble.

Hmmm, okay, that's a useful bit of info that is not detailed about the 3DO in many places...

I'd still like to get my hands on the partially ported code that was used as a base, not to mention the earliest version of the UQM code, since looking at them might prove useful...

I know I can grab the UQM 0.1 code from SF, but what about that partially ported code?


At the moment I'm a little wary of SDL for the DS. It's still very WIP and the last update was a few months back. The extent of this is that the current version doesn't even compile without a hitch on the current devkitArm. Which means I have to spend some time digging through the errors on that end before I can even start to try getting UQM to code...

*Sigh* If only I could rip it out and use PALib :-(

But I'm guessing that SDL is pretty closely hooked in at this point, right?

*Sigh*

Personally, I'm not really sure SDL is a good library to port to the DS, given it's  general project aims (Correct me if I'm wrong, but SDL's focus is more on promoting interoperability between OS platforms than architecture platforms...)

Well, blah, anyway, back to the hammer and anvil...

Oh, by the way, Toys For Bob replied. They were willing to look into it, but not right now, as they're extremely busy helping complete Tony Hawk's Downhill Jam (Not the DS version I think, since that's done by Vicarious Visions...). Well, hehehe, depending on where things are at in a few months, we'll see...

Try grabbing the initial import of UQM into SourceForge CVS (http://sourceforge.net/docs/E04/) (i.e. the start of the UQM project). That should be pretty close to the original TFB release.

Edit:

Another edit: be advised that this will (if you have the CVS client installed) slurp about a gigabyte of uncompressed WAVs together with the source code. Also, compiling this mess is non-trivial, as the Makefile seems to be broken. And the result just barely works. And even when it works, it eats up all your CPU power. Yuk.

Looking closer at the SDL implementation I linked to, I'm not impressed. Sound seems to be missing, too.

Considering that PALib (surprisingly, to me) seems to be much more mature (and better adapted to the DS's oddities), this could be a good idea.

Not as much as you'd think, actually. Most of UQM is actually not directly connected to SDL. Reimplementing the graphics, sound and input code in PALib may actually be a good idea. Of course, this means that you'll have to do some graphics converting (UQM is, IIRC, 32-bit PNG, PALib seems to be limited to 8- or 16-bit and is missing PNG support), but since the DS is a very specific target (as opposed to Windows, where you don't really what screen format you're going to have to work with), one can take advantage of this to optimise the graphics for the DS.

16-bit graphics (or 15-bit; my memory fails me here) are what the 3DO version used, so converting the UQM graphics to 16-bit shouldn't in most cases do much damage (the PC graphics were 256 colours from an 18-bit palette).

Sound in PALib is a similar case; batch convert the WAVs to a suitable RAW format (or write a WAV loader; it's not that hard for PCM samples). PALib plays 8 sound effects at a time (hardware accelerated, apparently) and reserves the other 8 channels for MODs, for which it has a built-in player (nice!).

SDL seems to focus on promoting interoperability between Unix platforms. Anything else is an unforeseen bonus. ;)

Seriously, the problem with SDL is that it makes a lot of assumptions that aren't valid on a console, such as having a keyboard, mouse and optional joysticks, having threading built into the OS, a Unix-like filesystem and so on. It mostly ignores hardware acceleration (especially the exotic forms used in consoles), preferring to rely on portable-but-slow brute-force approaches. You could try implementing SDL using PALib, but I suspect rewriting the graphics code in PALib could aid performance quite a lot (the sprite, zoom and scrolling features could be very useful in melee and planet sequences).

Roughly what I expected.

Thanks for all that info Novus. I guess I'm going to do some initial digging and start taking readings on just how much work replacing SDL with PALib would involve...

After that I'll probably do some cattle rustling over at GBADev and start putting together a concrete project plan for the whole thing...

Using the UQM code but removing SDL and using PALib might well provide the best of both worlds when it comes to the clone vs. port question. We'd get to keep the game logic and all that while being able to take advantage of the DS's hardware...

Anyway, I'm off back to my cave to do some more wrangling :-)

If you really want to try out the TFB release of UQM, forget about the autoconf et.c. stuff and just compile with (blatantly assuming you're on Unix):


On GCC 4, you may get a few errors about static definitions; just remove the word "static" from the offending lines until it works.

Well, just a minor update.

I'm currently in the process of going over the UQM source code in order to work out what the code in the various files does so I can get an idea of where to start changing things...

I've also gotten a sign-on from another GBAForums members who's interested in helping out :-)

Also, I've applied for a SourceForge page for the project. Hopefully I'll get positive news on that in the next few days...

Oopman, is there anything I can do to help? I can make sprites and such, maybe add a victory animation to the captains?

I can run homebrew on my DS Lite, so I can offer testing when the time comes. That's all I have time for sadly, or I would offer to help in more useful ways.

Thanks for the new replies guys.

In terms of game resources (Graphics, sound, etc) it's unlikely we'll need much, since UQM already provides pretty much everyone one could want . At the moment my primary interest is in getting som extra coders on board (Hopefully some with experience in either DS homebrew or working with the base UQM code...)

Testers will, of course, be welcome. Once things reach the stage at which extensive testing is required I'm hoping to test things out on as many homebrew devices as possible...

Okay guys, some more news...

Examining the source is taking some time (UQM has rather a lot), but it's proving fruitful and I'm getting a better idea of where UQM code is going to need to be changed. I am, of course, taking down all the details so that my co-developer(s) can also make use of this stuff :-)

In other news, SourceForge have approved my request for project space and thus UQM DS now has a proper base-of-operations. The project is available at:

https://sourceforge.net/projects/tau-qimp (https://sourceforge.net/projects/tau-qimp)

All further news updates and development info will be handled via the SourceForge page, so I'd apprecate it if a mod could lock this thread and, possibly, sticky it...

Stickying too many posts will prevent any of them from being read. For most visitors of this forum, your project just won't be interesting enough to warrant a sticky post.
I've added a list of ports to the Ultronomicon page on The Ur-Quan Masters (http://uqm.stack.nl/wiki/The_Ur-Quan_Masters) and a reference to this list in the forum FAQ, which is already stickied.

As for locking, I could do that, but people may still want to talk about this subject and this thread seems as good a place as any.

Good point, thanks for that...

Well, anyway, as long as development and bug related posts appear in the SourceForge forum I won't mind....

I don't want to end up doing a copy-and-past though ;-)

UQM on the DS? Would be music to my ears :)

Once it gets to the point that the interface needs to be retooled, I'd be more than happy to lend a hand in any new graphics that need to be done.

(yup...still alive...)

Well, development is currently in the planning stages but things are happening.

The development process will probably be faster now that I've had some luck getting a multi-threading library ported to the DS. Things on that end are still being iron out, but at the moment it's looking good...

Okay, just a slight update. We're still going, although I haven't done much with the SourceForge site yet.

My co-coder has been ill, so he's been unable to do much code-panning, so to speak.

I've been busy documenting the source structure while also getting this multi-threading library ported to the DS (Which seems mostly done now...)

Pretty soon we're going to start panning you watching UQM devs for some info on the graphics engine.

For example, here's one now:

How closely integrated is the GUI side of the engine with the gameplay window side of things? Is the GUI overlayed as a discrete step, or is it kinda jumbled together? Reason being it'll be easier to get the 1-screen-to-2-screens code hacking done if the GUI is overlayed discretely...

Well, anyway, prepare yourselves, UQM devs :-)

So, any update on the status of this project?

This is kind of off topic, but I just wanted to say that every time I see this title I almost crack up laughing and i'm not sure why.

There's an Ur-Quan in my pocket
and he's stealing all my creds.
His stare is blank and glassy
I suspect he's lost his meds.

[with apologies to G. Threepwood]

Hey all, sorry for not checking the thread...

Alas, bad news. I've put the project on hold. After spending a lot of time with the source I pretty much realised that my graphics programming skills are simply not at the level where I'd be able to do the port. Unfortunately none of my co-coders seem to have crackerjack coding skills either :-(

As I've posted on the SF project page, the whole thing is on hold until someone with actual graphics programming skills decides to help out.

I was hoping the port would not be too much of a mission to handle, but it seems that doing UQM any kind of justice on the DS would involve recoding various parts of the graphics engine, something I'm not really skilled in. The whole structure of the graphics engine is rather more complicated than I imagined it would be and really not suited to the graphics hardware of the DS (Which is very powerful on the 2D end if coded for specifically, but not so useful with graphics engines originally coded for the PC/3DO)

It would probably be possible to get a quick and dirty copy of the game up and running using the WIP version of SDL for the DS, but that would actually be a bit of a dead-end, since SDL DS at the moment does not have any kind of support for more than one screen and isn't exactly being worked on regularly...

Sorry to disappoint everyone. Hopefully at some point in the future I can get things going again, but that will rely on me finding someone who's totally comfortable with doing the kind of engine-mucking work that would be needed...

I would really like  quick and dirty port using only one screen, that would be better then anything.  I would definatelly play this.

Thanks