PocketMatrix

Unless your game is extremely trivial, and does not require full-screen updates at 30 FPS, then you can use the standard Windows API to render your game. Otherwise there is too much overhead using the system calls, which will grind your game to a halt.

The alternative is to use the Game API. Basically all this does is give you direct access to the display buffer, which eliminates all the Windows CE overhead. Most all Pocket PC displays use RGB 565 encoding, which is where the RGB color value is stored in 16 bits (2 bytes) using 5 bits for red, 6 for green and 5 for blue. Thus bitwise operators, like "shift", "or" and "and" are required to manipulate the color values. Blitting consists simply of copying memory around. You can use memcpy if your buffers are in alignment, otherwise you copy shorts (16 bit integers) manually.

So, you can handle all this yourself, or you can use one of the free 3rd party programming APIs such as EasyCE (see Phantom's Forum), PocketFrog or GapiTools, to handle some of the dirty work for you. They make it easier to support multiple devices by handling some of the hardware-specific issues for you (for example, the iPaqs display is really sideways, with the origin being the bottom left of the screen). All three of those APIs' forums are hosted here at Pocket Matrix.

Dan East

One of the problem with IMGDECMP.DLL is that it returns you a handle to a windows bitmap (HBITMAP). This means that if you want to access the actual pixels, you have to use a DIB. From what I remember, IMGDECMP.DLL actually returns a DIB, but there is no way (that I know?) to access the pixels on Windows CE. So basically, you use IMGDECMP.DLL to retrieve a bitmap handle, you create a DIB, then blit the bitmap to your DIB using a device context.

If you want to know how it's done, then I suggest you take a look at my PocketFrog library. All the source code is available. The code to load images using IMGDECMP.DLL is in file "image.cpp".

http://frog.flipcode.com