One of the major problems with the current implementation of the game was how resource management was handled. The resource managers were designed to prevent duplicate data from being loaded. This was all well and good, except that I had implemented an incredibly bad way for unloading resources, and essentially most resources were never getting unloaded until the game actually exited.
Most of the work I’ve done in the past two days has involved correcting these problems. Though, in the process, some duplicate data will now be loaded more than once. However, I have setup the game engine up so that future development will be easier to counter this problem.
Also, many of the classes have been modified to work in a more object oriented fashion. (Not that it wasn’t object oriented before, but now it is more-so). Many resource classes now load the resource in the constructor and delete it in the destructor. That way when a new instance of a class is created, it is created as a specific resource on the disk, and it remains that particular resource until it is deleted. This is so that resources behave more like the Java String class, which is immutable. Many of the resources are mutable (Meshes for example can be changed when they are animated), but there is little reason to reload a mesh with a different mesh file once it has been created. This also insures that a resource always exists, even if it wasn’t properly loaded (a bad file, for example). That way the resource may still be used (though nothing would get rendered if the mesh didn’t actually exist) without a null pointer causing an unexpected crash because a portion of the code thought that a particular resource existed, even though it didn’t.
I’ve also cleaned up some of the rendering code, and further abstracted the Direct3D interface. One reason I’ve modified all this resource handling is because I want to change the way the renderer works. Currently the renderer allows any graphic object to load textures, shaders, and materials, but I don’t like this. An object has no reason to work directly with textures or shaders, it needs only materials. Part of the reason the renderer allowed graphic objects to work with textures previously, is because some graphic objects loaded textures directly instead of loading a material file. I have decided that instead of allowing them to work with textures directly, they may still load a texture, but they will load it as if it were a material, and the renderer will create the material internally. This will also reduce some of the checking required when rendering vertex buffers, since the renderer will always know that a material is set, and not have to figure out if a specific texture, shader, etc, is set.