E.X.P.L.O.R. in development now! Cool Developer Stuff

Pages: 1 2 ...3 ... 5 ...7 8

Material Resources - May 30, 2011

In my last post I hinted that I wanted to redo the way textures and shaders are handled by the renderer. What I wanted to do was make it so that all textures are materials. Materials include properties such as textures, shaders, diffuse colors, specular colors, and other information. Previously the engine allowed textures to be loaded and used directly. Now a texture may still be loaded, but it will be loaded internally as a material with default color values and no shader. So now, instead of having SetTexture, SetShader, and SetMaterial for drawing triangles, there is only one method: SetMaterial. Materials can be loaded in three different ways. The programmer may specify the specifics of a material using a material definition class (CMaterialDef), they may specify a filename pointing to an XML material definition file, or they may specify a filename that points directly to a texture (in which case the material is created internally).

Resource managers for all of these resources have been implemented as well. Thus insuring that a shader, texture, and material get loaded only one time, and are deleted only when all references have been released. So for example, more than one material may refer to more than one shader, but that shader will get loaded only one time (the same goes for textures). And more than one mesh might refer to the same material, but that material will only get loaded one time.

This finally corrects all of the resource management problems I had previously. Now resources are properly deleted in the engine when they are no longer used, whereas, previously, resource cleanup occurred when the game shut-down. Now resource cleanup can properly occur between level loads, for example.


Categories: Development

Resource Management 2 - May 28, 2011

So I re-implemented the resource managers for game assets. Specifically for meshes, skeletons, and skins. I decided to handle the resource management internally within the specific classes for each resource type. Now each type of resource is created and deleted using static member methods, and the constructors and destructors have been made private (to insure that only the static methods can be used to create the resources). The resource manager itself is a static member, and at the start of the game the resource manager must be created, which is also accomplished using a static member method. So, for example, the mesh resource manager is initialized by calling CMeshEG::InitMgr(), and is shutdown by calling CMeshEG::ShutdownMgr(). In between these to calls a new mesh can be creating using code similar to the following: CMeshEG* pMesh = CMeshEG::Create(mesh.emesh). It would then be deleted by CMeshEG::Delete(pMesh).

The Create method implements the resource manager, and so if a duplicate resource is created it returns the reference to the original resource, rather than creating a new one. A reference counter is incremented when a duplicate resource is loaded. And the Delete method reduces the reference counter, actually deleting the resource when the reference counter reaches zero. Additionally, when ShutdownMgr() is called all resources within that manager are deleted and a warning is sent to the console of any resources that were never properly deleted, thus the programmer may locate any problems they may have had with not properly deleting resources.

Similar systems have been implemented for Skins and Skeletons. This is a much cleaner way of handling resource management than I had done previously. As it doesn’t rely heavily on additional classes (well, it sort of does, but all the additional classes are internal private sub classes, so the programmer never even has to look at them).


Categories: Development

Resource Management - May 27, 2011

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.


Categories: Development

AI Controllers - May 24, 2011

Alright, I implemented the ability for one AI to access the AI controller of another entity. The main reason I did this was so that when the door that I’ve implemented is activated it can tell from what direction the activating entity is activating it from. In this way the door can decide to open inwards or outwards for a more natural door opening reaction. That is, the door opens away from the activator. That way a player wouldn’t have to move out of the way when opening a door that swings towards it.

Of course one AI activating another will also have other useful benefits for other AI operations such as implementing weapons, shooting, conversations, etc.


Categories: Development

Making Noise - May 13, 2011

Today I worked more on the problem of implementing a working door in the game. Specifically with regards to sounds. Previously an entity could only make a sound based off of it’s animation. When the appropriate animation hit the specified frame a sound would be played. This was well and good for syncing sounds with animations, but an entity like a door isn’t animated, it is a physical object that moves in the world, and so when it needed to play a sound, it’s AI had to decided when the sound would be played.

An entity definition file allows sounds to be assigned to the entity. Now, the AI controller interface allows the script writer to play any sound associated with the entity whenever they choose. In the case of the door that I’ve developed, the sound is played when the door is activated, that way as the door opens it makes door opening sound. This portion of development involved coding on both the client and server side of the application, as well as an additional structure for NetComm.

Also, in developing the ability for an entity to play one of it’s sounds. I discovered a bug where the position of the the sound being played was not properly being set. In fact, any time a sound was played, it was played at the last position where it should have been played instead of it’s current position. Something I had sort of been aware of since the footstep sounds that I implemented previously seemed to be playing all over the place and not necessarily where the entities were standing.


Categories: Development

1 2 ...3 ... 5 ...7 8

Search

This blog chronicles the development of the Emergence Game engine. The Emergence Game Engine will be a fully functional 3D game engine with support for the latest technologies in video game development. This blog features the remarks of the lead programmer, Blaine Myers, as he comments on the struggles and joys of developing a 3D game engine.

Categories

Recent Posts

  XML Feeds

CMS + user community

Rough Concept Skin by Beem SoftwareMultiple blogs solution