The Ur-Quan Masters Discussion Forum

The Ur-Quan Masters Re-Release => Technical Issues => Topic started by: GodNnelg on October 05, 2006, 07:21:58 pm



Title: Working on DS port, need help!
Post by: GodNnelg on October 05, 2006, 07:21:58 pm
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?


Title: Re: Working on DS port, need help!
Post by: Novus on October 05, 2006, 08:20:29 pm
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.


Title: Re: Working on DS port, need help!
Post by: GodNnelg on October 07, 2006, 08:46:00 pm
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..


Title: Re: Working on DS port, need help!
Post by: OOPMan on October 07, 2006, 08:50:30 pm
What we were wondering, really, is whether or not the UI is rendered in a discrete fashion. In other words, is it overlayed after everything else?

However, it looks like this is not the case :-(


Title: Re: Working on DS port, need help!
Post by: Novus on October 07, 2006, 09:29:32 pm
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.


Title: Re: Working on DS port, need help!
Post by: meep-eep on October 07, 2006, 10:20:45 pm
I've had little to do with the graphics handling in UQM myself, but I do know some things about it.
The graphical output is built up of what the source calls "frames". A frame takes up a part of the screen, and is defined relative to a parent frame. So if you add a screen number to the definition of a frame, and set it for the top frames, and add knowledge of this screen number to the drawing code, you'd only need to change a few coordinates in some of the outer frames.
So adapting the screen layout for the DS should be fairly easy.


Title: Re: Working on DS port, need help!
Post by: OOPMan on October 08, 2006, 11:27:18 pm
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...



Title: Re: Working on DS port, need help!
Post by: meep-eep on October 09, 2006, 01:57:00 am
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.

Quote
And the GUI stuff along the side is part of a cascading frame network?
They're nested frames, if that's what you mean.

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

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


Title: Re: Working on DS port, need help!
Post by: Rogue Kohr-Ah on October 09, 2006, 02:07:39 am
From the sounds of it he wants to, but I'm betting he's not going to for long when he tries.


Title: Re: Working on DS port, need help!
Post by: OOPMan on October 09, 2006, 10:07:43 am
Hrrmmmmm....

meep, what are these frames referred to in the source code itself?

You said they're not referred to as frames. Are they the oft-used "contexts" that I've seen scattered about?


Title: Re: Working on DS port, need help!
Post by: Novus on October 09, 2006, 11:06:49 am
If I'm not mistaken, UQM renders everything to an off-screen buffer first and then blits the entire buffer to the screen.
More or less. Sometimes, it only blits the changed parts for speed.

Quote from: OOPMan
You said they're not referred to as frames. Are they the oft-used "contexts" that I've seen scattered about?
That would be them. The division is not very fine-grained (the status bar on the right seems to be one context, for example, the radar one and the main screen one).


Title: Re: Working on DS port, need help!
Post by: OOPMan on October 09, 2006, 01:22:21 pm
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...


Title: Re: Working on DS port, need help!
Post by: meep-eep on October 09, 2006, 04:22:18 pm
meep, what are these frames referred to in the source code itself?
'FRAME'

Quote
You said they're not referred to as frames.
I did not say that.

Quote
Are they the oft-used "contexts" that I've seen scattered about?
No, although they are related. 'CONTEXT' is used for specifying parameters for drawing. There is a concept of 'active context', and different contexts are made active before drawing different things. Contexts do not have a hierarchy.



Title: Re: Working on DS port, need help!
Post by: OOPMan on October 09, 2006, 06:43:58 pm
Okay, woops on that...

So, do FRAME types have an associated buffer of some kind for storing image data?

Time to use that Find in Files feature of Crimson Editor I think...


Title: Re: Working on DS port, need help!
Post by: meep-eep on October 09, 2006, 08:04:36 pm
I suggest you use some editor which can find definitions of types. It's pretty easy to find answers to questions like this then.


Title: Re: Working on DS port, need help!
Post by: OOPMan on October 09, 2006, 09:52:45 pm
Yep, did that :-)

Oh the joys...

A frame.c with no frame.h and FRAME defined in drawable.h

What fun :-)