Wednesday, June 1, 2011

Systems layer makes a comeback

The first thing I did today was the removal of the initialization game state, replacing it with the systems layer.  The "systems layer" is a collection of objects/systems common to all game states.  Examples of these are the main window, Direct3D device, and timing system.  Currently the systems layer is a collection of scope pointers in the application layer's Run() function.

Something I realized while working on the systems layer is that I no longer need the window manager.  The purpose for the window manager was to have a constant place for the window procedure to exist.  Now that ownership of the main window isn't being transferred between game states repeatedly, I can put the window procedure in the application class.

With the systems layer in place, I was able to easily give the main window code a pointer to the current state safe pointer.  When the main window receives the WM_CLOSE message, it calls the IGameState::WindowClose() method on the pointer.  The actual code looks a bit ugly due to the whole pointer-to-a-safe-pointer thing, but at least it works: m_state.Get()->WindowClose();

I also put the basic rendering code in place.  This gave me the chance to try out the COM wrapper idea I mentioned in a previous blog post, and it's working great!  Using a generic wrapper is a lot easier than creating a wrapper for each interface.

While writing the timing system for the fixed timestep, I decided to take a closer look at the conversion from int64 to double which is required when using QueryPerformanceCounter/Frequency().  My main concern was losing precision.  I looked into doing integer-only math for the timer, but I quickly remembered that not using floating-point math for timing in a fixed timestep had caused problems in the past.  I eventually decided to just cast to double like usual, and fix the problem when it is actually a problem.

No comments:

Post a Comment