Rocket

Rocket is my first Direct2D program. It is graphics only, no sound.

Rocket runs in a normal Win32 window, so it is no problem to mix GDI and Direct2D operations and the old familiar Windows messaging system is still there. The downside to this approach is that the offscreen image needs to be painted onto the window, which is an expensive operation. It typically takes 3-4ms to draw all the objects to the offscreen image, then 16-18ms to paint the image to the window. This is acceptable for programs where the display changes infrequently, but not for action games where the refresh rate is a critical statistic.

UPDATE: The above statements were not entirely correct, the "paint method" has exactly the same performance as the officially sanctioned, but more complicated, "SwapChains" method. The timing measurements were misleading. The "draw" operations were merely updating the sprite locations and did not paint any pixels. All the graphics operations were buried inside the paint call. This misled me into thinking the final bitblt was taking more time. The over-arching frames per second measurements were identical for both the paint and swap-chains methods.

The worst of the DirectX stuff is wrapped in the MyD2D class in the Util project.

The Rocket program consists of 5 major components:

1. Main: The container for the main window. This handles all the window messages, player input, and manages the Game and Image objects.
2. Game: This class encapsulates all the game logic, including all the ItemList.
3. Image: Manages rendering the items to the Direct2D target.
4. ItemList: Manages all the game items. This is a simple list manager.
5. Item: The individual game items, including the rocket, bullets, and rocks. The game logic and mechanics for the individual items are found here.

Main.cpp

The global ghD2D object is created before the window. This performs all the "factory" creation and initialization for Direct2D.

I need to resize the image whenever the window is resized.

I paint the image to the window in response to the WM_PAINT message. This is also where the image is created. I can't create the image until the final DC for the window has been created, which I can't be sure until the first WM_PAINT.

The game is periodically updated in response to a WM_TIMER message. Main::MsgTimer() calls GameUpdate() to update all the game items. The window is then invalidated to trigger a WM_PAINT message.

Game.cpp

The Game class encapsulates all the game logic. This includes initializing a new game/level, updating the game items, and determining when the game/level is over. The Game object contains the ItemList, Image (created by Main), Arena dimensions, and control state.

This class is pure logic, it performs no graphics operations directly.

The first thing is to create the ItemList object to manage all the items. Then the hItems is filled with the initial game items: the rocket and a bunch of random rocks.

CreateItem() is a simple function that creates a new Item and adds it to the ItemList.

When the Main object creates the Image, it needs to share it with Game so it can be used during the GameUpdate() calls.

Game needs to know when the size of the Arena has changed so Game can share that information with ItemsList where it is used in the update logic for the individual Items.

Game translates user inputs from keystrokes into control state flags, which are used during the game updates.

The Game is updated by telling ItemList to update all the items, resetting the Image, drawing all the items to the Image, and finalizing the Image.

Image.cpp

The Image performs all the graphics operations needed to compose each displayed video frame.