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

Imagine if I was an unashamed David Brin fan and wanted uplifted dolphins in a game. Oh wait, that's you Neonlare :-)

Yay, Space Empires V has been released...

Hehehe, if you really really love MOO2-type games, then this is the one to go for. SE is, as I've said before, like MOO on steroids. Leagues ahead of Gal Civ II as well :-)

Space Empires is like MOO on steroids...

I'm eagerly looking forward to SE V :-)

Anne McCaffrey: No thanks. Some of her older SF is okay, but her more recent stuff has been pretty limp. The Pern stuff is okay-ish, but a lot of her more recent stuff and a lot of the stuff set in the Ship universe (The Ship That Sang, The Station That Fought, etc, etc, I've probably got some names mangled) is fluffy in the extreme.

Raymond E. Feist: Mostly over-rated. Keep in mind, however, that I'm one of those "old skool" types who prefers Fritz Leiber's style of fantasy, rather than this awful heroic fantasy crap that gets churned out by a network of seemingly identical authors to a formula (Good vs. Evil with a serving of Sex, Violence and Cliches on th side...)

Hehehe, CJ Cherryh for the win, I say!

[port]

Gar, why is it that people keep suggesting these kind of changes...

Last time I checked, UQM was a port, not a clone...

And a bloody good thing too..

Gal Civ II's expansion pack also looks to be a depth-wise improvement on the game, providing more stuff...

I believe GC2 does feature tactical combat though, although I thihk GC1 didn't...

Also, GCII isn't actually a Civ-rehash :-) It's a 4X game. You remember Master of Orion, right?

As for Alpha Centauri. One of my favourites game. Ever.

Hmmmm, I was just reading a preview of the expansion pack to Galactic Civilizations II when I made a stunning realisation...

They stole StarCon 2's plotline!!!

Kind of...

Korath = Kohr-Ah?
Kynn = Ur-Quan?

Looks that way to me...

Read the preview, it's kinda funny...

Yep, did that :-)

Oh the joys...

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

What fun :-)

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

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

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?

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

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

Hey! They're a three-for-one deal and have some crackingly funny dialog...

Too bad you let them die :-)