After a long time I realized that the engine wasn’t very well architected. By this I mean that all the components were lumped together and were interfacing directly with each other more than they should. I decided to do a COMPLETE REWRITE of the entire engine (maybe using some snippets from here and there) using a better structure.

I have been working on the new design for about a month now and it is starting to come together. Here are some of the major changes to the engine:

• SDL is no longer part of the engine core. A new window management system will be used instead. This will allow the engine to be ported more easily to consoles and PC platforms without SDL support.
• The graphics API has been abstracted to a Renderer system. This uses an interface to allow more APIs than just OpenGL. This way DirectX, LibGCM and other APIs can be implemented. This also means that other engine components don’t need to deal with API-specific code.
• The game state system has been simplified. Now “states” are called “games” and should implement their own state management system.
• User input is now managed by an input manager interface.
• Different components are placed in their own sub-directories and namespaces.

CPPGEN

The current design lists more than 40 different classes, and the engine design is only about half complete at this point. Once the technical design documents have been drawn up and the structure is finalized, creating close to 100 class definitions will be tedious work.

To make this simpler, I hacked together a Python script to do it for me. All I have to do is write an XML file defining all the namespaces, directories and classes and cppgen will create everything for me. Right now it’s fairly simplistic and will generate class definitions of the form:

#ifndef NS1_NS2_CLASSNAME_H
#define NS1_NS2_CLASSNAME_H

namespace ns1 { namespace ns2 {

class ClassName
{
public:
    ClassName(void);
    ~ClassName(void);
};

}}

#endif

Where ns1 is the main namespace, ns2 is a sub namespace and ClassName is the class’s identifier.

It does not handle member properties, methods, inheritance or interfaces yet, but it could in the future. I would also like to extend it to generate getters/setters for properties and function definitions.

Right now the code is very messy and needs cleaning up before these features are implemented but it is in a usable state at this point.

Interested? Check it out on Github.

In my quest to get shaders working I have learned a few things. I am almost 100% happy with the system now. There are a few issues to resolve before I move onto something else. A number of major changes have taken place during the past few weeks.

• I have re-written the material format. It is back to XML and supports diffuse color, normal mapping, specular highlights, glow and falloff highlights.
• A number of pre-defined variables are provided to the shader programmer providing an interface between the engine and GLSL.
• Tangent-space is calculated for each model when it is loaded and is stored in the data structure.

Issues to resolve:

• Multi-light rendering
• Multi-pass rendering for special effects
• Absence of some textures isn’t functioning as it should.

I tried for two weeks to get Cg working with the engine but all I was getting was a lovely black screen. This morning I gave up, removed all the Cg stuff and tried out GLSL. Worked perfect first time. I have written a simple shader program which displays the view-space normals rather than the model’s colour. My plan is to get deferred rendering working because it allows for some clever tricks.

So after a few weeks of fruitlessly trying to figure out how to integrate a GUI system into the engine I have decided to abandon the project. The reason for this is two-fold: I couldn’t figure out the mechanics by which I could use it and not have a massive overhead when it wasn’t required. It also turned out to be more effort than it was worth.

As a result, I think the scene editor might have to move to another project seperate from the engine. I’m going to stop thinking about it for now and focus on the rest of the engine. I still have all the files etc in SVN and I still have the data models I drew up so I can return to the project again another time.

You can now check out the latest re-structure of the engine from the Google code project.

I am using the mmgr memory manager to find memory bugs and there are currently no issues (it finds something wrong with the linked list class but I think that it’s OK).

The GUI system is getting a total re-write to fix some major issues.

That’s all folks.

The exams are over and I’m working on improving the engine further.

After lengthy consideration, I decided that it would be best to write my own GUI system from scratch rather than using an existing one. This creates a learning experience for me and avoids unnecessary overheads. It also means that I can make the UI operate in any way I want it to. It also allowed me to develop a work flow I can use in the future for adding new features:

CIDIR – Concept, Ideas, Design, Implementation, Refinement

Concept

For the GUI, I decided that I wanted to go for a simplified of the Blender UI system. I produced a mock-up in Photoshop to get ideas circulating.

Ideas

I begin to think about how the UI would be used, what it’s function would be and how customizable it should be. I decided that I wanted the GUI to be fully customizable in C++. I also considered scripting with Lua, Python or Ruby. I decided against this in due course. Scripting may be a feature for another time. I also begin to think about how I would write the systems and how they would be used later.

Design

A final software design is compiled describing classes, interfaces, inheritance, etc; as well as a list of API functions. A implementation plan is also laid out.

Implementation

The software is written according to the design and is regularly tested to ensure that systems work as expected as they are brought on-line.

Refinement

Does the feature work as expected? Are there any bugs? Are any design changes needed? If the answers to any of those questions is yes, changes are made and the feature is reassessed.

I’m sure that there are better work flows out there, but this one works quite well for me at the moment.

The GUI is not yet finished and a lot of systems are waiting to be brought online. I am using a version which is quite different from the one in the repository at present. I have separated the engine and the demo parts into different projects. The engine is built as a static library which can be used by other games or other applications. My current solution also uses an early version of the scene system. I have a newer version of the scene system in another project but it isn’t working at present for a multitude of reasons. When the GUI is working I will complete and integrate the newer scene system back into the project.

In a future post I will talk more about the GUI’s design and structure.

I’m going to stop working on the engine for a while. I’ll continue once my exams are done and when I have some more motivation. Until then, this is what I have been working on:

• New scene model. Maps will now be known as scene and a new class and data model has been devised using a more flexible, faster and expandable format.
• Scenes are will not same kind of file format as the maps.  I’m going to have a go at binary streaming and if it works, I may convert models and materials over to the same system.
• A new file system will be implemented to handle file loading. This will make alterations and restructuring easier.
• Each object will have a bounding box and ellipsoid generated automatically.
• The scene will be split using an octree system.
• The scene will have a single underling piece (or pieces) of geometry which will be handled by the renderer and physics quite differently.

UPDATE:

Have done the odd bit here and there. I have the new scene file format working. Scene objects are implemented along with core scene data using the new binary streaming method. There are still lots of bugs to iron out and a plethora of features to add. Right now it is all still very experimental and unstable so don’t expect any SVN updates for a while

Getting the engine to figure out if two objects are intersecting sounds easy, but it isn’t. I have spent the last week trying on and off to figure it out. I tried several tutorials and even some existing physics libraries but no dice… yet.

I’m goint to try the Open Dynamics Library now. It seems to work well and has been used in a few AAA titles recently so I guess it’s pretty good. I figure it’s worth a try.

For the first time in a while I actually thought about what kind of game I would want to make when the engine is in a usable state.

Well so far so good. The engine seems to load quickly and run smoothly. I can have an assortment of models on the screen each with their own material. The optimizations are great and I’m very happy. According to ohloh the entire project is only 2.8K lines of actual code but there is much more to come. Most importantly, physics and collision detection which is a vital part of any game.

As an extra note: if anyone out there wants me to post working binaries, just leave a comment.

XML seemed like a good idea at the time but now I have it implemented in the engine, it’s butt slow. I’m going to have to look at other solutions.

The system I am working on right now is quite similar to the XML format (here is a sample representation of a cube). The vertex data is given in the form of what I call a “Vertrinity” (a trinity of position, normal vector and texture coordinates, 8 floating-point values delimited by a double colon ‘::’). I have a modified version of the old Blender exporter and  a stand alone C++ parser which works great. Now I just have to integrate it into the engine. Yay.

Update 1:

It works! Models are now loaded using the new format and it is much faster. The rendering also seems to have sped up a bit but that may be a happy side effect. I am looking into using vertex buffers for storing the vertex data on the graphics card rather than in RAM for a bigger performance boost. I still need to get materials and maps using variants of the new format so I can eliminate TinyXML from the project (BTW, TinyXML is still a great library but it’s just a matter of using the right tool for the job). Anyways, enjoy a screenie

Update 2:

And now I have the new map format working! (see a sample here)