|
Pages: [1] 2 3
|
 |
|
Author
|
Topic: There's An Ur-Quan In My Pocket! (Was: The Ur-Quan Masters DS...) (Read 11289 times)
|
OOPMan
Zebranky food
 Offline
Posts: 44
|
Hi all, new forum member here...
Anyway, I recently posted the idea of doing a port of SC2 to the Nintendo DS (See this 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...
|
|
|
|
« Last Edit: September 30, 2006, 09:51:59 pm by OOPMan »
|
Logged
|
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
|
|
|
|
|
Novus
Enlightened
Offline
Gender: 
Posts: 1938
Fot or not?
|
How complex is the UQM source? Are many elements of the single-player game hard-coded?
The source is... complex. Most of the adventure game logic is right there in the C code.
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?
Most of the libraries UQM needs seem to be available on GPF's development site.
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.
|
|
|
|
|
Logged
|
|
|
|
OOPMan
Zebranky food
Offline
Posts: 44
|
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...
|
|
|
|
|
Logged
|
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
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.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
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.
In this case, you'd probably have unload unused resources (graphics, sounds) to a greater extent that UQM currently does. Could be hard work.
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.
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.
Threading is used, but not extensively. Just for things like blinking selection boxes. So you could do without that.
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 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.
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.
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.
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).
|
|
|
|
|
Logged
|
|
|
|
OOPMan
Zebranky food
Offline
Posts: 44
|
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...
Enjoy, and feel free to drop any thoughts and comments...
|
|
|
|
« Last Edit: September 07, 2006, 06:29:53 pm by OOPMan »
|
Logged
|
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
OOPMan
Zebranky food
Offline
Posts: 44
|
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...
|
|
|
|
|
Logged
|
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
|
|
|
|
|
|
|
OOPMan
Zebranky food
Offline
Posts: 44
|
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...
|
|
|
|
|
Logged
|
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
I know I can grab the UQM 0.1 code from SF, but what about that partially ported code?
Try grabbing the initial import of UQM into SourceForge CVS (i.e. the start of the UQM project). That should be pretty close to the original TFB release.
Edit:
cvs -d:pserver:anonymous@sc2.cvs.sourceforge.net:/cvsroot/sc2 login
cvs -z3 -d:pserver:anonymous@sc2.cvs.sourceforge.net:/cvsroot/sc2 co -r tfb -P sc2
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.
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...
Looking closer at the SDL implementation I linked to, I'm not impressed. Sound seems to be missing, too.
*Sigh* If only I could rip it out and use PALib :-(
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.
But I'm guessing that SDL is pretty closely hooked in at this point, right?
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!).
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...)
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).
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...
Roughly what I expected.
|
|
|
|
« Last Edit: September 08, 2006, 03:17:12 pm by Novus »
|
Logged
|
|
|
|
|
Pages: [1] 2 3
|
|
|
|
|
