Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
71 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

 Game Technologies

 Printable version
 Discuss this article
 in the forums

Game Technologies

While DirectX isn't there, you're not completely out of luck. There are some technologies that'll ease the pain of losing DirectX.


GAPI, formally GameX, is a technology that MS licensed that allows direct framebuffer access for games in a reasonably portable way. It's without-a-doubt the fastest way to throw pixels on the screen, but it's got a couple of drawbacks.

GAPI is simple. It's only ten function calls. After initializing GAPI with GXOpenDisplay(), you can call GXBeginDraw() to get a pointer to the framebuffer. GXGetDisplayProperties() returns a structure containing the properties of the display, including bits per pixel, width, height, X pitch, and Y pitch. The pitch values specify the distance between pixel values in the buffer, because a framebuffer is not necessarily a 240x320 array of 16-bit values. It's up to the hardware maker how the video memory is organized.

In addition to framebuffer access, GAPI gives you a relatively platform-neutral way of accessing the PocketPC's controls. This is important because while some handhelds like the Casio and the iPaq have nice little direction-pads, some like the new HP PocketPC decided to clone tha Palm's horrible four-horizontal-keys layout. GXGetDefaultKeys() returns a struct containing the standard key-values that PocketPC supports, so you can easily check to see if a key is down.

While GAPI's strengths are that it is very simple and does the job it sets out to do, it has a couple of weaknesses. First off, it's propriatary. While there are GAPI DLL's available for Casio, Compaq, and HP, there aren't any such DLL's available for other models or form-factors, and you're beholden to Microsoft if any new PocketPC models come out.

Another problem with GAPI is that direct framebuffer access precludes all of the nice window commands. If you want to draw a line, some text, or stretch a bitmap, you're on your own.

Finally, GAPI doesn't run on the emulator, which gets rid of some of the advantages of developing on-screen as mentioned in the previous article. Thankfully, though, an intrepid hacker wrote a GAPI DLL that indeed works on the emulator. It is available here.

The DIBSection API and CEAnim

If you don't need to throw pixels at the screen at the highest speed possible, and you want very good speed without worrying about what new platforms are coming out and whether or not GAPI will support them, you should look at the Win32 DIBSection API. It's been around since Windows 95, and it works.

DIBSections are weird birds. Back in the days of Windows 3.1, there were only two different ways to handle bitmaps, DDB's and DIB's. DDB's (Device Dependent Bitmaps) are owned by the video driver and are in whatever format the driver prefers. They are very fast to display but have one gigantic drawback -- you can't change the bits once you've created the bitmap. If you want to change the bits, you need to create a new bitmap, which make it far less than optimal for displaying frames of animation. The second method is the Device Independent Bitmap. A DIB's memory is owned by your application, but drawing the bitmap to the screen requires the video driver to convert the bitmap to screen format, which makes displaying them much slower than DDB's.

In the latter days of Windows 3.1, Microsoft created the much-maligned WinG. WinG added a third bitmap type that combined the best of both worlds. You could modify the bits directly, and you could display them to the screen quickly. Several console games were ported using WinG, like Earthworm Jim and a few other scrolling platform-games.

The WinG API survived into Windows 95 as the DIBSection API, and it still exists today. Using CreateDIBSection(), you can create a buffer of memory that's shared between the application and video driver. You can change the bits as necessary and blit the buffer to the screen very quickly using the standard old BitBlt() command.

CEAnim is an extensive class library for Windows CE by Random Software (www.randomly.com). It leverages the DIBSection API to the hilt to provide all kinds of animation effects, including sprite animation, alpha blending, dirty rectangle management, and palette management. On the whole, it's much more more extensive and high-level than GAPI.

In addition to graphics, CEAnim includes a library of common data structures and memory management functions. Best of all, though, is that it addresses a problem caused by the loss of DirectSound -- wave mixing. There's a sound class that can play multiple sounds at once so you don't have to cripple the sounds in your game.

It's certainly worth a look. Download it at ftp://www.randomly.com/src/ceanim_src.zip. If anything, check out the author's CE offerings at the web address above to see the kind of things you can do.

The DOOM and Quake Engines

Direct3D and OpenGL don't exist for PocketPC, but you're not out of luck if you're looking for 3D that fits in your pocket. Both Doom and Quake 1 have been ported to PocketPC, and you can use them to develop your own projects. The engines for both Doom and Quake are both freely available and use the Gnu Public License, so you can freely use them in your own projects -- even commercial ones!

QuakePPC source code and binaries are available here. DoomCE source is available here. The terms of Id's licenses are available here.

Next : Conclusion