0.9.7:Overview of recent changes
From DXFWiki
This document attempts to explain a few major changes from 0.9.6 to 0.9.7 in more detail than the change log.
Contents |
Visual Studio 2005
With version 0.9.7 DXFramework has moved to Visual Studio 2005. Support for older compilers has been completely dropped because there is a free version of Visual Studio 2005 available on the web.
New singleton design pattern
The way that the DXFramework singletons are programmed and used has been significantly changed.
See the FAQ item "What is this Instance() function? (Singletons)" for an introduction to this change.
The two ways it will affect users familiar with 0.9.6 are the usage of dxf::Game in main.cpp and the game state classes.
dxf::Game in main.cpp
Instead of declaring a Game object in main(), a pointer to the instance to the Game object is retrieved using its Instance() method.
dxf::Game* const pGame = dxf::Game::Instance();
Also, the Game object does not need to be Unload()ed anymore.
Game states as singletons
The demo game states have all been converted to use the new singleton semantics. This is not technically necessary (registring states the old way still works), but it does clean up registrar.h a bit since the states do not need to be members of the registrar class anymore, they are retrieved in a static context whenever necessary.
The general pattern
Here is a great overview of the general singleton design pattern used in DXFramework:
Precompiled headers
See the FAQ item "What are precompiled headers?"
Fixed pathing issues
Version 0.9.6 was very unforgiving as to what directory it needed to be started in because it would look for the media and data files in a very inflexible manner. This has been fixed in the latest version and therefore the program should work fine without setting the working directory project setting or running the executable in a specific place.
Although it is more flexible, the executable should still be placed "close" to the media folder. It searches for this folder starting with the current folder, then its parent folder, then the grandparent, then it looks at the directory the executable is in, and then its parent, and so on.
As a general rule, keep the .exe with the media folder either both contained in the same folder, or perhaps in a folder contained in the same folder as the media folder.
Moved resources file
The resources file (.rc file) has been removed from the engine component and moved to each executable's project (such as Demo, WorldMap, etc.). This is just a more simple way to separate project resources and was requested by students last fall.
New (moved) DXUT project
The DXUT component of the engine has been moved out of the engine folder and in to its own project. This is to facilitate debugging and speed up compile times, and also to facilitate updating the DXUT component when updates are released.
GameState, GUI, GameStateGUI classes
The GUI class proved to be very confusing and has been removed. The functionality now exists in both the GameState and GameStateGUI classes.
The old GUI class was necessary to get the methods and members necessary to use the very convenient DXUT widgets. Now, simply derive your state from the GameStateGUI class instead of both GameState and GUI.
When using the derived GameStateGUI class, it is very important to follow the following rules:
- Call GameStateGUI::Load() first thing in your state's Load() method.
- Call GameStateGUI::Unload() first thing in your state's Unload() method.
- Put placement and sizing logic in your state's Resize() method, instead of in the constructor or in the functions used before.
- Call Resize() in your state's Load() method to set the initial size and placement of your GUI objects to reduce code duplication.
- Create a MsgProc method for the class and place this line first thing in it (you can put your own MsgProc logic after it):
if (GameStateGUI::MsgProc(hWnd, uMsg, wParam, lParam)) return true;
- Define OnGUIEvent() for your state, this is the callback where you get events related to your GUI objects.
- Do not override the methods OnResetDevice(), OnFrameRender(), OnGUIEvent(), OnCreateDevice(), OnLostDevice(), or OnDestroyDevice() unless you know exactly what you're doing.
GameState simplified
GameState has been slightly changed to make things a bit easier.
- It is only necessary to provide definitions for Load(), Unload(), Update(), and Render2D() now.
- Although you don't need to override MsgProc(), you usually want to in order to intercept the ESC key. The engine, if it gets this message, quits, and this can be very annoying.
Disabled C++ Exceptions
C++ Exceptions have been completely disabled. This is a performance thing. You can enable them if you really want to (Project properties -> C++ -> code generation).
New projects created using Python script
Microsoft changed their template system, the old one was clunky. Unfortunately, the new slick template system doesn't support C++. I figured it would be much easier just to write a simple script for creation of new projects. See the starting a new project page for more information.
