PocketMatrix

I'm a new developer in Pocket PC and I wanna develop some GAPI games. I been trying to write  directly to the screen buffer with my own BltBlt function but encounter alot of problems.<br>Recently I found of a new way of drawing to screen througnt the help of the Microsoft's DIB and BltBlt. It goes like the<br><br>My sprite --(Using Windows Bltblt)--> DIB --(Using memcpy or my own BltBlt)--> Framebuffer<br><br>The good thing of this method is the I can use the Windows Bltblt to handle the loading, resizing, transparent, etc. I sure this method is slower but how much? Currently, I using memcpy for normal sprite and pixel copy for transparent and alpha sprite. If u have a better method of posting sprite to screen, please advise. Codes and example will be nice. Thanx.<br>

ello,<br>well, it's hard for me to say exactly how much slower it is, but I guess quite a lot. Especially the Pixel copy for transparent and alpha blended sprites is surelly really slow. The bitblt/memcpy might be not so bad...<br>They way to make it right (fast) is to use GAPI and do all your graphic functions yourself (or use a lib...) You might want to check easyce (www.pocketmatrix.com/phantom/ - go to tech page for full source download) , it is a great lib with all the initialization for GAPI and some simple drawing functions included.<br>Good luck!

To put it simply, if you can use GAPI, then use it.  For instance, Quake would be completely and utterly unplayable with the wind bitblt function.  The 720 actually accelorates it, and it still is way to slow.  There are several reasons why (ok maybe only one or two), but all you need to know is that comparing bitblt to GAPI is like comparing a moped (SP) to a formula 1 racing car.

Rob, <br>I'm curious to know how much slower Quake ran by using BitBlt rather than a custom GAPI blit routine.  From what Dan has mentioned before, the majority of Quake's time is spent doing floating point calculations rather than blits.  I would think that it should only be doing one blit per frame - from the back buffer to display RAM.<br><br><br>

GAPI is way faster. I am just writing a general purpose gfx library to simplify bliting etc. for people who are starting pocket pc game programming. So far I have:<br><br>LoadImage/BitBlit/MaskBlit/TextOut/TransparentBlit<br><br>If you want help with gapi blitting please just email me!<br>

Simon (and others),<br><br>Saying something is "way faster" doesn't carry much weight.  If you're going to provide a library of routines for people to use, that has as its primary value to be faster than the available blitting routines provided by GDI, you should post profiling results between the two.<br><br>

Simon:why do you code it? There's EasyCE already, you might rather want to add something to EasyCE so we have a more complete library.

EasyCE is a framework, I just wanted a library of functions for stuff like masked/alpha blitting. Since I am going to release the source code with no restrictions it would be easy to add into EasyCE if anyone wanted to do that.<br>

I think Bitbank once tested the speed of BitBlt on PPC and found that the routine ran around 30ms. That's 3fps, not nearly fast enough for anything but board games.

I don't believe it's 30ms, really.

Er, I can believe GDI BitBlt is 30ms, which is 33 fps surely. 1000/30 == 33 ish.<br><br>Of course you wouldnt get 33 fps because the game would have to be doing other things too.<br><br>Maybe it is less though, the only way to be sure it to time it yourself <br><br>You can easily get 10ms for a fullscreen copy with a pixel by pixel copy in c++, and about half that with some optimization. Obviously to get exact figures it needs proper timing trials, but there is certainly no doubt that GAPI is faster than GDI by a large margin.

BTW: I was talking about an iPaq 36xx for the rough timings in the above post. The speed would of course vary wildly depending on processor speed.<br>

I had another thought <br><br>One other major factor would be the pixel format. A 256 col screen should blit twice as fast as a 4096/65000 col screen.<br><br>Anyway, I might run some speed tests on the GDI tomorrow if I feel like it. I suspect the real penalty for games with the GDI will actually NOT be the BitBlt function, but things like DrawText and the shape drawing functions which have loads of extra options you wouldnt normally need, but must take their toll on the speed.<br>

Simon:well, if you can't get the backbuffer->frontbuffer copy in under 10ms you're having a poor start to get 24fps which is your tft screen refresh rate(as far as I know, might differ from device to device)

I dont really see why. If, for instance, I wanted 24 fps, that would give 40ms per frame. If the pixel per pixel copy with format conversion takes 10ms, and a full screen optimised blit takes 5ms, that gives quite a bit of time to do everything needed.<br><br>It doesnt really matter in the end, as my newest gfx routines are working fast enough that the game I wanted them for needs to be slowed down to make it playable.<br>