Thread: UrQuan Masters!
View Single Post
ZerionSeven's Avatar
Posts: 68 | Thanked: 84 times | Joined on Mar 2007 @ Lappeenranta, Finland
#68
Originally Posted by Serge View Post
Well, I already commented that in quake2 thread Judging from N800 hardware capabilities, software RGB->YUY2 conversion is just a useless waste of cpu cycles. The only reason to use it is the missing software interface to support this feature (Xv only supports YUV formats). RGB hardware scaler is also exposed through pixel doubling API, but is somewhat more limited as it is restricted to 2x scaling only and does not have tearsync enabled (BTW, xserver patch to force tearsync for pixel doubled screen updates is trivial). What do you think, is it worth submitting a feature request asking for some API for RGB hardware scaling support in maemo bugzilla? Technically there are many ways to achieve that, for example RGB565 color format support could be added to Xv, looks like NVidia already supports 32bpp RGB color formats, so using Xv for RGB formats is not something completely new: http://osdir.com/ml/video.vdr.softde.../msg00022.html).

The only drawback is very slow deployment of these improvements to end users as they will require xserver update and it is only updated with new firmware releases. But without doing anything now, we may just wait forever and be forced to keep using inefficient screen update methods for the games which need low resolution
It would obviously be better to have scaling of the RGB formats directly and not have to waste time with the color conversion, and I don't see how it could hurt to have a request for the feature. I'm fairly new to all this maemo stuff, and software development in general, so it would probably be better if someone with a bit more knowledge about these things than me would write the request.

Actually as I've written in the quake2 thread, I've optimized the conversion to a point, where even with overhead caused by it, the SDL_DisplayYUVOverlay with a 400x240 image scaled to 800x480 seems to be so much faster than doing SDL_UpdateRect with XSP pixel doubling that it actually gets better fps with the overlay. Also, with overlay, I can do partial screen updates, which I believe is broken with XSP. Though I've not yet made an version of UQM to use the faster version, since it will need some changes to make it work with 16-bit surfaces, where quetoo uses only 8-bit, and I've been a bit busy with other things lately.

Originally Posted by El Amir View Post
on this website:
http://sc2.sourceforge.net/downloads.php
the debian contents ae not available no more...
any other links?
The content links are working fine for me. They are not debian specific, but the .uqm files at the bottom half of the page, atleast the uqm-0.6.0-content.uqm is needed to play the game. Or if you're looking for the N800 debian packages for the game program itself, you can get that from http://www2.lut.fi/~thietan1.