After the prototyping done in Phase 1, it's time to take the rough, dirty, and basically entirely stolen code and turn it into a framework that can be used for the future. This means it needs to be extensible, flexible, cleanly designed, and capable of handling all of the configuration and power that we need from the engine (stuff like screen resolution changes, et. al.).
The core framework is currently split into sections for the Win32-specific logic (message pumps and all that), a generic framework for building dynamic application loops, and some various utility classes. There is also the interesting bit, the rendering system. The renderer accesses a DirectX wrapper which then takes care of putting the pretties on the screen.
The most interesting feature so far is the dynamic application loop system, which is an idea I had on the spur of the moment today and decided to explore. Basically, instead of a giant GameLoop() function that calls all of the other systems (renderer, game logic, AI, sound effects, netcode, etc.) there is a single dispatch system that uses generic "callback" objects to trigger specific pieces of code. This dispatch system is currently built to allow multithreading, although I'm not really planning on making use of it, at least not yet.
The dispatchers are basically the while(I_am_still_running) loops for the program; each time the dispatcher loops, it goes through a list of registered callbacks and triggers each one. My plan is to set this up as a std::map that automatically orders the callbacks by priority. Callbacks can be added or removed at any time.
The upshot of this is that the game logic, and what executes, is fully configurable. For instance, I could set up the Renderer and UserInput callbacks at the beginning of the program (as they are now) and not remove them at all. Then, I can add in a MainMenuLogic callback that runs, then is removed and replaced with a PlayGameLogic callback, or a ShowCredits callback. The entire system is configurable and dynamic, and as a (very hefty) bonus, the actual game loop code doesn't have to know a darn thing about what each callback does. I'm seeing a lot of potential in this system and I'm getting excited to start playing with it and see what can be accomplished.
At this point, the engine consists of a paltry 11 classes and 2 POD structures. It is a valid and fully functional Win32 application, as well as a more-or-less operational Direct3D client. It also has a basic rendering loop that draws a little habanero pepper moving around in circles on the screen:
I hereby declare Habanero: Phase 2 conquered. Phase 3 will be to build a scene and camera system for the renderer that lets me set up batches of pretties to draw on the screen, handles shaders, and all of that good stuff. The core framework will be enough to consider Phase 3 complete, as I'm absolutely certain that the actual rendering system will be getting tweaked, improved, and revised up until we kick this thing out the door.
