Thanks, fossil.

Your spec-reading skills are fine, and I believe your suggestion is good -- although I cannot test that in the near future: I had to send my device to Nokia maintenance because of faulty wlan chip. The scratchbox dev. environment is pretty neat, but sound is obviously something that cannot be tested on it...

I just figured you were removing features that require too much CPU power or memory to run.

Sure. There are two additional things I'm thinking of:
1. Getting rid of external dependencies that are not part of the Nokia/maemo base installation is top priority (considering that Maemo is a debian-derivative, the dependency-handling on it is laughable -- there is no dependency handling for user installed software!).
2. I don't want to stray too far from UQM proper, at least not yet. I'd prefer changes that can be committed upstream...

You should be able to remove Vorbis support by editing the files in src/sc2code/libs/sound/decoders; removing oggaud.* and removing the references to Ogg Vorbis in decoder.c ought to do the trick (I'm surprised there isn't a build configuration option for this).

You were correct. I have removed the dependency, and actually added a build option for it. I'll file a bug in bugzilla, and send a patch.

You may also want to remove .DUK video and audio support while you're at it.

Do you think I'd win anything except make the package smaller?

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

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

Yeah, Tremor is what I currently have -- but I don't think I'll be keeping it: I believe the only way to use the larger content packages would be to use the external rs-mmc disk for storing it (even that would usable only for a small amount of people as Nokia ships only  a pitiful 64MB rs-mmc with the device), because of limited internal memory.

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.

Thanks fellas, that'll get me going...

[*) Nokia 770 Technical info:]

I now have uqm running acceptably on the maemo platform / Nokia 770 ^*, and I'm currently looking into what kind of settings I should change to make it more enjoyable.

 I've already halved the "Low quality" SDL audio frequency and channels (into 11025 and 1) in audiodrv_sdl.c. This lowers the amount of buffer underruns to almost zero. If someone has a hunch about the lower limits of "acceptable quality" regarding those numbers, I'd love to hear it.

 Is there something else  (sound/video quality-wise) I should take a look at? 

 There is a dependency for vorbis libs, but my content pack (uqm-0.5.0-content.uqm) doesn't seem to contain any: Are oggs used only in the larger content packs? Can the dependency be easily dropped, or am I missing something?

Also, any general performance hints are greatly appreciated.
Thanks,
 -jussi

*) Nokia 770 Technical info:
processor: TI OMAP 1710, 220 MHz ARM
fpu: none
memory: 64MB RAM + 128 MB Flash (+rs-mmc)
screen: 800*480*16 TFT

[Left of screen]

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.

That wasn't too hard...

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.

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?

I just tried to compile and run uqm on Scratchbox (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:

Code:

Initializing base SDL functionality.
Using SDL version 1.2.8 (compiled with 1.2.8)
Using config dir '/home/jussi/.uqm/'
Using '/home/jussi/uqm-0.5.0/content' as base content dir.
Warning: There's no 'packages/addons' directory in the 'content' directory;
        '--addon' options are ignored.
Saved games are kept in /home/jussi/.uqm/save/.
Initializing Pure-SDL graphics.
SDL driver used: x11
SDL initialized.
Initializing Screen.
Couldn't set 640x480 video mode: Maximum supported bitdepth is 16
Could not initialize video: no fallback at start of program!

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