Establishing a Build Environment - Android NDK Game Development - page 22

5. After the application's window is created, we have to run a typical message loop:

MSG msg;
while ( GetMessage( &msg, NULL, 0, 0 ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
…
}

6. This program only handles the window destruction event and does not render

anything. Compilation of this program is done with a single command as follows:

>gcc -o main.exe main.c -lgdi32

How it works…

To render a framebuffer on the screen, we need to create a so-called device context with an
associated bitmap, and add the WM_PAINT event handler to the window function.

To handle the keyboard and mouse events, we add the WM_KEYUP and WM_MOUSEMOVE cases
to the switch statement in the previous program. Actual event handling is performed in the
externally provided routines OnKeyUp() and OnMouseMove() , which contain our game logic.

The following is the complete source code of the program (some omitted parts, similar to
the previous example, are omitted). The functions OnMouseMove() , OnMouseDown() , and
OnMouseUp() accept two integer arguments that store the current coordinates of the mouse
pointer. The functions OnKeyUp() and OnKeyDown() accept a single argument—the pressed
(or released) key code:

#include <windows.h>

HDC hMemDC;
HBITMAP hTmpBmp;
BITMAPINFO BmpInfo;

In the following code, we store our global RGBA framebuffer:

unsigned char* g_FrameBuffer;

We do all OS-independent frame rendering in this callback. We draw a simple XOR pattern
( http://lodev.org/cgtutor/xortexture.html ) into the framebuffer as follows:

void DrawFrame()
{
int x, y;