An Innovative wireless PDA Game Leung Pui Yin, Carol Lo Man Kit, Marcus

Outline  Introduction  Technologies in our project  Pocket PC programming techniques  Snapshot of our project  Future work  Conclusion  Q&A

Introduction  Current Pocket PC game  Two players only  Wired connection  In our project, we will implement a complete wireless multiplayer Pocket PC game on Bluetooth

Technologies in our project  Bluetooth  Game API

Technologies in our project  Bluetooth  Two Bluetooth equipped devices can establish a connection together within 10 meters range of each other.  It utilizes a radio-based link, so does not require a line-of-sight connection in order to communicate.

Technologies in our project  Game API  Handling graphics much more efficiently  Useful to write blazing-fast games

Difference between GDI and GAPI User Code Display Hardware Display Driver Video Memory Windows GDI Device Context Display Hardware Display Driver Video Memory Windows CE GAPI Device ContextUser Code

Advantages of GAPI  By bypassing Window CE GDI entirely, Game API allow programmers to directly access to Pocket PC video memory.  It is useful in writing high-performance, real-time games.  It is useful for video playback and other graphics applications.

Limitations of GAPI  No support for “BitBlt” or “TransparentImage”  Need to write a custom BitBlt routine by the programmer

Pocket PC programming techniques  Pocket PC limitations  Computational Power  Memory  Screen Size  Due to these limitations, there are some problems that are not encountered in desktop PC programming.

Pocket PC Memory Management  Shutting down applications without notifying user when memory is low  Happens when an application needs more memory, e.g. instantiate more objects

Pocket PC Memory Management ThresholdValueDescription Hibernation200 KBWM_HIBERNATE message sent to longest inactive application Low- memory 128 KBWM_CLOSE message sent to longest inactive application Critical- memory 24 KBNo new applications can be opened.

Pocket PC Memory Management  Implement a handler for the WM_HIBERNATE message  Attempt to release as many resources as possible  Avoid being closed unnoticeably

Game API  Conventionally, the origin of a window is at the upper-left corner.  Also, the pixel bits in a bitmap are organized in horizontal rows.  However, the video memory retrieved from GAPI may NOT be organized as stated above, depending on the model.

Game API  CASIO Pocket PC series  Normal  HP iPAQ series  Origin at lower-left corner  Organized in vertical column

Game API  Solution 1 - use GXDisplayProperties  *(VidMem + x * GXDisplayProperties.cbxPitch + y * GXDisplayProperties.cbyPitch)  Accessing a pixel needs TWO multiplications, which are quite slow in Pocket PC, especially when bitblting.

Game API  Solution 2 - use specific code for different model  Much faster, comparing  *(vidmem + x * cbxPitch + y * cbyPitch)  *(vidmem++) in a for loop  Troublesome to develop  Many publicly available packages use this method

Thread  Sprites movement and graphics update are performed one by one in game loop.  Problems  The job of sprites movement may be lengthy.  The job of sprites movement would be done in a controlled way.  Frame rate may drop.

Thread  According to 1/10-second rule mentioned by Charles Petzold, the job of sprites movement should be handled separately by another thread.  In our project, the job of each sprite movement and graphics update are handled by separate threads.

Thread Pool  Thread creation and thread termination are very time consuming.  Both thread creation and termination occur frequently in a multi-player game using multi-threading.  We need to speed up these processes.

Thread Pool - Basic Idea  Create enough threads at initial phase to avoid dynamic allocation of threads in the middle of the game.  Not to terminate unused threads – reuse them when appropriate.

Object Pool  Similar to thread pool, the aim of object pool is to reduce the overhead of object creation and termination.  The major difference is that object pool has to manage different kinds of objects.

Snapshot of our project

Future work  Wireless Multi-player game  Synchronization problem on Bluetooth and Pocket PC

Conclusion  Developing games on Pocket PC has its commercial values.  It is a challenging task, involving many latest technologies.  It needs some attentions not commonly noticed in desktop PC programming.

Q & A