Game Engine, Draft 2

Well, here we go again.

My old game engine discussions start here.

It was recommended to me on the GameDev.net site that I take a look at the books 3D Game Engine Programming and OpenGL Game Programming. From that, I'll study the differences between what I attempted before and what those authors did.

To start out, I'm expecting to do these things first:

• Establish a good vector class with math operators so my vector operations aren't overloaded with function calls like they were before (vA = vB + vC instead of vA = vB.AddVec(vC))
• Build a good array and list template class, with the list class having deleted list functionality. I'll probably base them on the STL, making sure they don't result in too much memory fragmentation.

The reason for this is these items will appear all over the place in my code, and if I go with something else later, it will require changing a lot of references throughout the source.

Mistakes I made in the first draft:

• Treating the initialization routines for each primary component as a virtual function to be overridden. This setup is more troublesome than intuitive. I hope to learn a better way of doing it.

From the books, I'm hoping to learn the following:

• A good structure for base game classes
• Clean use of global objects and singletons where necessary
• Intuitive initialization and code setup
• Avoidance of spaghetti code from all the class-class references
• How to avoid the number of classes getting out of control, possibly coming up with a good naming convention for them to help keep them straight (since VC 6.0 doesn't enjoy keeping your classes in folders for you in the class list)
• Fast and intuitive setup of a new project

Stay tuned, no promises. I really hope to come up with a base that everyone can use.

....

Well, I picked up both books this morning and have been programming a new vector class guided by the 3D Game Engine book. Some of the code didn't compile immediately without some small corrections, and I forgot that VC 6.0 doesn't recognition external reference to inline functions unless you put their implementation inside the .h file. Other than that, so far, so good.

It might take a while before I realize whether or not it helps me restructure my game engine in a better way.

I'm also concerned about how I can design a matrix class that can be used easily with both OpenGL and Direct3D without having to reverse one for the other, and how the vector class could be used to assemble a matrix class without rewriting a lot of the routines.

The 3D Engine book also works with 4 element vectors (with a w component that is always 1.0) and matrices that are truly a set of _11 thru _44 floats, instead of my f, l, u vector arrangement. I'll keep going with it.

* Important note - some of the operation routines in the matrix and vector classes actually alter the parameters at times (as an example, if you pass a vector to the matrix class to build a rotation matrix around an arbitrary axis, it WILL get modified). I don't know if it was done this way for speed or if the author isn't used to obeying the "integrity of parameters" rule, if there is one. It just seems like it's very easy to have something modified when you weren't expecting it, and having to hunt the bug all the way into the math routines, or realize you just didn't know the rules of the routines. As a coder, I prefer to protect the users more, but it does slow things down slightly, too. There is also a routine that transposes a matrix, but the swaps are intermixed without saving the old values. I don't know if it will work right if you're flipping the same matirx into itself.

EDIT - whoops, turns out the matrix building routine accepts the vector by value, not by reference. So normalizing it in the routine doesn't affect its source. I've been away from programming too long.

.....

I'm entering the graphic classes in, and realizing that there is a difference between a static library and a dynamic link library (DLLs). Apparently the static DLL is the one that's always loaded (and likely required to run) while the dynamic ones are loaded only when needed, as the code in the static library's routines suggest.

How this helps me restructure my engine in a way that is really helpful is yet to be seen.

I also saw that the Release routine for the renderer ignores whether or not the ReleaseDevice function was successfully loaded from the DLL before CreateDevice is allowed. I figured a safer design would prohibit the class from performing graphic functions until it can load them all. I understand in a devlopment project that a test DLL can be made available sooner without having to develop the Release function first, but I would still have done it the safer way.

.....

What I'd like to include in my new setup is the following:

• A clean WinMain and base message loop
• Implementing key-controlled minimization of the program and changing to windowed and fullscreen
• Menu states of the engine or possibly form-driven operation
• Project setup (as it applies to my engine, but only to make new programmers aware of what's involved)
• ... more...

.......

I'm beginning to realize that working on each component separately and pulishing them as a DLL might help get the class names in 6.0 under control. As long as the class names are only listed when the .h files are included, it shouldn't be a problem. Each DLL could have its own stub-test project that I can freely modify the .h files in. If I'm working on an actual project and I realize a change to the .h's are necessary, I'll have to test the modification in the test project and provide it to the final project. this also avoids a lot of final project rebuilds when the core components need to change.

I made a Win32 Static Library project and it only compiled a .lib. I made a second project, linked the .lib to it, and called the two functions within the .lib which created a class for me. I called a couple of functions and then released it.

I managed to access the class memeber by including the .h for the class - the project remembered the class members even after I removed the .h file from the project. I went back and added a SetVal member to the class, and the implementation project still only remembered the out1 and out2 members. I suppose to update, I'll just include the .h again.

** I made a second project that makes a dynamic library (DLL). It compiled and made a DLL but no lib. What if I want it to be required for a program instead of loading it dynamically? How do I get it to make a LIB?

Also, I read a warning that VC 6.0 might not apply the export functions in a .DEF file, so they should be delcared as declspec(dllexport) in the function definitions. You can also export classes like this: class _declspec(dllexport) GEMatrix {};

.......