Standard Windows Procedure function here. On the WM_CREATE event, we initialize DirectDraw, and set our g_bActive flag to true, so our GameLoop function is executed. When WM_CLOSE is called, we want to set our active flag to false (again, so our app doesn't try to draw to our DDraw screen after its been destroyed), then call our CleanUp function, and finally destroy our window. It's important that you handle the WM_MOVE and WM_SIZE events, because otherwise DirectDraw will not know the window has been moved or resized and will continue drawing in the same position on your screen, in spite of where on the screen the window has moved.

The infamous InitDD function… but wait, it's only several lines! This is what the common libs were made for! We now have all the DirectDraw setup garbage out of the way, effortlessly! Again, you'll notice that it's done a lot for you. If you don't really care to know the exact procedure of what has been abstracted from you, at least get the gist of it. It will help out if you have to go back and change the cooperative level or whatnot. Note that this is a boolean function, so if you like, you can do error checking (which I, for some reason or another, decided to omit in this article).

Simple enough. This function calls on the SAFE_DELETE macro defined in dxutil to delete our display object, and call the destructor.

This is where you'd want to put your game. In order to give you an example of how surface objects work, we've made a simple text surface and drawn some text onto it. Note that we destroy g_pText at the end, because it is recreated every cycle and not doing so would eventually eat up quite a bit of memory.

The longest function in our application, WinMain. As usual, we setup our window class, create our window, show and update it, and go into the message loop. The loop is different from usual because we dont want the processing of our game to interfere with the processing of messages. We use our g_bActive flag to see if its safe to call our game loop, which involves blitting things onto the screen, and at the end of it all we finally return lpMsg.wParam (I'm honestly not sure why, but thats how it's done in every other Win32 app, so oh well).