|
Pages: [1] 2
|
 |
|
Author
|
Topic: Working on DS port, need help! (Read 4988 times)
|
GodNnelg
Zebranky food
 Offline
Posts: 2
|
Hey me and Oopman (and a few others) are looking to port UQM to the DS.. but after looking at some of the code we're not sure what scripts reference the UI and create it..
Anyone know?
|
|
|
|
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender: 
Posts: 1938
Fot or not?
|
What, exactly, do you mean by "the UI"? The menus, status screens and such are, basically, all over the place (usually together with the game logic for the relevant section). It's probably easier to explain which parts of the code don't reference the UI. Most of it seems to be concentrated to the sc2code/ directory, though.
If you explain exactly what you're looking for, I may be able to be more specific.
|
|
|
|
|
Logged
|
|
|
|
GodNnelg
Zebranky food
Offline
Posts: 2
|
The hope was that maybe somewhere admidst everything, UI might be seperate but thanks for clarifying..
Lets start someplace simple then.. two things of interest to me at the moment:
Which scripts 'dont' reference the UI and.... well.. I'm curious about what script controls the menu options you get (while away from planets) as well as the script for the ship inventory..
I just realized now that that may not be simple at all lol sorry..
|
|
|
|
|
Logged
|
|
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
Near as I can figure, most of the game is written using the good old "change something in the game state, then redraw what needs to be redrawn" style. Thus, the combat gameplay code is pretty badly intermixed with the combat status display and combat view code and so on. It's all over the place, so much of the graphics code seems to be pretty much adapted from the 3DO code with the low-level stuff rewritten instead of being rewritten entirely. The easy way out would be to split the UQM 320x240 "screen" into chunks and modify the low-level graphics code to copy them separately to different places to change the screen layout; this is, of course, not very flexible, but it would save you from having to go through most of the UQM code and painstakingly change everything.
Most of the race-specific stuff (dialogue and ship logic) seems to be pretty cleanly separated from the rest of the code, but that's it, really.
|
|
|
|
|
Logged
|
|
|
|
|
|
OOPMan
Zebranky food
Offline
Posts: 44
|
Hmmmmm...what you say is pretty interesting meep...
So, that would mean that the main gameplay window (Main during combat/space nav) is a single frame then?
And the GUI stuff along the side is part of a cascading frame network?
That could be helpful...
Gah, at the moment things are looking a little bleak. Reason being, the DS only does a standard framebuffer mode on one screen at a time. The other screen has to run using one of the peculiar modes...
What it really looks like, at the moment, is that adapting a standard framebuffer using game to the DS could be quite difficult, unless you just plan to do a straight dump, framebuffer to framebuffer.
This would probably be simplest, but the final game screen would have to be resized down and would be unpleasant to use...
Hmmmmm....
You know, if we could just disable all the UI related drawing and put together our own UI, that would work better. I don't know whether this is possible or feasible, though...
|
|
|
|
|
Logged
|
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
So, that would mean that the main gameplay window (Main during combat/space nav) is a single frame then? Yes, though as I said, I'm not an expert in the graphics part of the game.
And the GUI stuff along the side is part of a cascading frame network? They're nested frames, if that's what you mean.
Gah, at the moment things are looking a little bleak. Reason being, the DS only does a standard framebuffer mode on one screen at a time. The other screen has to run using one of the peculiar modes...
What it really looks like, at the moment, is that adapting a standard framebuffer using game to the DS could be quite difficult, unless you just plan to do a straight dump, framebuffer to framebuffer. If I'm not mistaken, UQM renders everything to an off-screen buffer first and then blits the entire buffer to the screen.
You know, if we could just disable all the UI related drawing and put together our own UI, that would work better. I don't know whether this is possible or feasible, though... You really don't want to do that.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
|
|
|
|
|
|
OOPMan
Zebranky food
Offline
Posts: 44
|
Hmmmm, well, that's pretty fine grained enough for the most part...
What about the Date/Location info bar at the top of the main window? Is that part of the main window context?
Well, anyway, I'll have to look into adding some screen functionality into the whole frames thing then. I'd like to fork as little as possible from the original code, though. Updates would be easier to intergrate that way...
Still doesn't get around the weird framebuffer problem though. Ah well, I'm going to look into using one of the special HW background modes as a replacement.
It follows that a special HW background that has it's source in an image can be treated as a software framebuffer. Although I'll have to make sure this is the case. Still, seeing as how you can have animated backgrounds and so forth, I think it's a good path...
|
|
|
|
|
Logged
|
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
|
|
|
|
|
|
|
|
|
|
Pages: [1] 2
|
|
|
|
|
