Thursday, February 19, 2009

Some comments about DirectX on Windows Mobile

Some comments about DirectX on Windows Mobile

I'm a Symbian developer, who is currently porting a game to Windows Mobile 5.0. I’m trying to use the DirectX and I naively thought it will be easy, but soon I found it is quite fuzzy and tricky. This forced me to make up this blog to share what I have found and get some comments and tips from experienced developers.

1. Hardware flipping support

First surprise was for me that how many devices do not support the surface hardware flipping. This results in fact that I was forced to blit the content of the back buffer instead of just flipping it. I do not know why I expect the hardware support here – probably because I always connected the DirectX with desktop PCs…

I found here
"…From the above code example, note the check for whether the device is capable of "Flipping" surfaces rather than BLT'ing them to display memory. For the vast majority of emerging Windows Mobile platforms, hardware flipping is not available…"

There is nothing to do with this, just accept it...


Secondly I thought that the back buffer could be created in the VRAM, but the API call always fails when specifying the DDSCAPS_VIDEOMEMORY flag. When I checked the video memory size it returns me some small values (HTC Wizard 200 (Qtek 9100) – 0 bytes, HTC Kaiser 120 (MDA Vario-III) – 153600 bytes, hp iPAQ hw6915 – 28800 bytes). I was not able to create back buffer in VRAM, so I created it in the system memory, which slows the blitting operation again. I do not have any idea what the VRAM is supposed to be used for or how to use it…

I found here

“…1) From what I've come to understand is that most devices have JUST enough video memory to house the primary surface. Sometimes the device has a bit of extra video ram left which is why the free video memory amount is so small.

2) Creating surfaces in video memory generally doesn't seem to work as there isn't ever enough room there to create a big surface. Maybe small ones that are <= to the free video memory size…”

Any ideas how (if) it can be used?

3. Transparency

I have, without any optimization about 25-30 FPS when the whole scene was rendered (no user interaction). When rendering just one bitmap (size 240x180px) the FPS was about 100. Unfortunately when I started to use the color key to specify the transparent parts of bitmaps the FPS falls to 5.

As written in the discussion here
“…I'm doing some blitting with alpha-test (I need to draw some sprites) but when I use the normal blitting with the DDBLT_KEYSRC flag, I lose much in performance (e.g. when I blit a 240X320 bitmap I have 220 fps but when I blit it with DDBLT_KEYSRC flag to lose the background, I get a fps of about 17 ?!)... for the moment, I’m doing the alpha-test myself by locking the surface and checking each pixel, which brings me a fps of about 25 for the same case... I've also tried doing it using GAPI, but I couldn't get a fps higher than 20…”

The only possible solution I can see there is to try to decrease the number of rendered sprites and simplify the way they are displayed plus I could possibly try to make my own routine for transparency handling, but I do not believe this will give me some more FPS. I welcome any hints on that…

No comments:

Post a Comment