The Ur-Quan Masters Discussion Forum

I just tried to compile and run uqm on Scratchbox (http://www.scratchbox.org/) (a cross-compilation toolkit for the Nokia 770 Linux device). Compiling was not that difficult, but trying to run uqm in the 800x480x16 environment (still on my host machine, running ordinary i386 code, just in a Xnest window) resulted in this:
"Maximum supported bitdepth is 16" comes from SDL_SetVideoMode according to the code...

I'm quite new to SDL -- what the hell does that mean? Is 16-bit not possible without OpenGL?

Thanks for any help.

Hmmm... I just tried setting my host X server to 16bits, and running  uqm there (with same settings as scratchbox). That works fine in a window and in full-screen.

So what's going on?

Two theories:

• Scratchbox's version of SDL (or Xnest) doesn't support any more than 16 bit colour (and is failing to decrease the bit depth even though UQM is telling SDL to use whatever bit depth is available!). Try editing the SDL_SetVideoMode call in UQM (src/sc2code/libs/graphics/sdl/pure.c) to use 16 bit colour instead of 32.
• Xnest has some problems with running at a different bit depth than the host server.

...I actually knew that is the case but somehow didn't connect.

Changing the call to SDL_SetVideoMode works! Thanks Novus.

That wasn't too hard...

(http://koti.welho.com/jkukkone/sc2-menu.jpg)
(http://koti.welho.com/jkukkone/sc2-melee.jpg)

the only problem i see is the lack of buttons (unless they're on the back, or you use those that are next to the pad)

Otherwise it looks kick ass  8)

The controls are a problem.

There are enough buttons I believe (although my muscle memory doesn't tell me how many were used in SC2...). There are 7 (not counting the four-way rocker) of which 2 shouldn't / can't be overridden:
Left of screen
* enter (inside the rocker)
* cancel
* menu
* home  [maybe should not be used]
On top
* maximize/unmaximize [should not be used]
* plus
* minus
* on/off  [should not be used]

The biggest problem is that the four-way rocker is actually very uncomfortable for fast action -- it is ok for starmap, but pretty much unusable in Melee in UQM. . . On the other hand using the stylus to fly might work: There is a Doom port (the true sign of a living platform ;)) that has this "stylus control area" on the bottom of the screen, so you achieve somtehing-like-mouse-precision control without covering the screen with your hand.

Nice. Did you have to change much?

Meep-eep: Surprisingly little. The only "real code changes" were the bitdepth thing discussed here and fixing too high sampling frequency in music playback. The rest were packaging problems related to getting the app installed and running on the device.

It took me one evening, but someone more familiar with maemo (the dev platform) would probably have done it in less than an hour -- this is a good indication that Nokia made a good choice when they decided to put a more-or-less standard Linux distro in the 770.

How's the speed?

Sometimes there are quite bad slowdowns in melee, sometimes it's entirely playable^* -- the difference seems to be related to whether I start the app from the command line or from a menu (...odd, I know. I don't currently give maemo-desktop the "Hello-my-name-is-UQM--please-add-me-to-runnning-apps-list-etc" -signal, maybe this is related to that).
 
EDIT:
*) entirely playable == slow, but not slow as molasses

Looking at pure.c again, there seems to be a lot of 32-bit surfaces being created. Changing them to 16-bit may speed things up, if you haven't done that already. You may have to do a lot of hacking to do this, though, as UQM seems to be running at 32 bits internally. However, I think the graphics system is probably the greatest time sink right now. Does turning the scaling off (using 320x240 mode graphics) speed things up much?

I've been working on unscaled mode all along (the screen on the 770 has a whopping 225 pixels per inch so pixel doubling doesn't look that bad) -- it does seem to help a little.

I'll take a look at the surface creation, although I have to admit I don't understand much when it comes to SDL (or graphics in general).

I did some experimenting; on my hardware (Athlon XP at 1800 MHz, nVidia GeForce 4) pure SDL mode is noticeably slower (15-20 % CPU) in Melee than OpenGL mode (5-10 %) (640x480 graphics, pure pixel doubling, no sound). Changing between 16 and 32 bit colour X server, however, doesn't seem to have any effect. I'm not entirely sure what's causing the slowdown on my system, let alone your 770.