Some of this information may end up published here. Some may not. But this part is at least.

Every FBX file consists of a single scene. This scene consists of a tree of nodes, which in the FBX SDK are from the KfbxNode class. The head of this tree is the root node, which is a dummy node. It is not saved into files, and therefore you do not ever want to put any crucial information into the root node.

Below this node is the tree of child nodes. Each of these nodes are of the KfbxNode class. Each of these nodes are connected to another class, called the KfbxNodeAttribute. It is THIS class that actually contains the elements of the scene. For example


typedef enum
{
eUNIDENTIFIED,
eNULL,
eMARKER,
eSKELETON,
eMESH,
eNURB,
ePATCH,
eCAMERA,
eCAMERA_STEREO,
eCAMERA_SWITCHER,
eLIGHT,
eOPTICAL_REFERENCE,
eOPTICAL_MARKER,
eNURBS_CURVE,
eTRIM_NURBS_SURFACE,
eBOUNDARY,
eNURBS_SURFACE,
eSHAPE,
eLODGROUP,
eSUBDIV,
eCACHED_EFFECT,
eLINE
} EAttributeType;


Those are the different attributes. You see obvious ones, like a light, a mesh, a skeleton (or more specifically, a bone from the skeleton). The others are not as obvious, but this is where everything in the FBX file is defined.

This is a complex topic that is not documented well online at all – so we’ll be back to this another day.

However, it is not flexible enough for my general needs. I intend to add to it as the next class progresses. It needs a good lighting system. It needs a terrain system. It needs lots of things it doesn’t have yet.

Everything is too hardcoded to be of any use right now. I’ve made a texture manager, but it looks for the three textures that I have and no others. If I wanted to add another texture, it would take lots of grueling hand-crafting to add it.

I need to build the back-end in a way that I can quickly and easily create as many different demos as I want. This is going to take some refactoring that will not show on the screen all that much, but will be essential to the health of the engine.

Hopefully I can continue to add to the demo, to the point that there’s a point to making new videos. But I may have a few weeks here where there is no outward change in how things look.

I have been concerned about this for awhile because it seems to be an open secret in the graphics hardware world that AMD’s support of OpenGL isn’t quite as good as NVIDIA’s is. But on the other hand, I don’t want to just jump to a “this company sucks” kind of conclusion. Odds are there is something I’m not doing quite right, seeing as I have a little less experience than the millions of man hours that have gone into NVIDIA and AMD’s history.

I realized this morning as I got to work (away from my desktop, so I can’t test anything just yet) that GLUT has a glutInitContextVersion() function that allows the user to define the version of OpenGL they are using. I haven’t been using it, and while OpenGL defaults to 3.3 on my laptop, that’s also the highest level it supports. Perhaps my desktop is defaulting to 4.2, which doesn’t compiler shaders right or something?

I have a new video to put together to show off the basics of a GUI that I’ve been putting together for my engine, but while everything looks great on my laptop, it doesn’t work at all on my desktop, which is the whole basis for this post. It’s annoying, and makes me wish our school was using DirectX rather than OpenGL for its work. Maybe I should maintain two versions of my engine, one in OpenGL for the classes and one in DirectX for my ‘professional’ portfolio. I don’t really intend to work outside the Windows work anyway, unless I’m going to consoles, and then XBOX uses DirectX too, whereas the PS3 and PS4 use proprietary graphics libraries that I’ll have to learn anyway.

This is mostly just me thinking out loud, but it’s useful to get things down in writing, in a linear fashion. Helps organize my thoughts. Time to play around with the engine some more.

Well, to be honest, my biggest reason for focusing on OpenGL is that we use it in our game classes at DePaul University. If we used DirectX instead, I’d be working on that instead. However, the perspective from this side of the fence has been interesting. DirectX has quite a few helper classes available to it, such as a font class and math classes that you can just plug and chug away. With OpenGL, I have to do this type of work on my own. It has forced me to really think about the representation of a font in a program, for example, or even a simple GUI. How does a slider bar work exactly? How does it get drawn? I appreciate this lowest-of-levels look at programming.

Most online resources for OpenGL tutorials still focus on the fixed pipeline of OpenGL 2.1 and earlier. This functionality still works just fine, and probably won’t go anywhere in GPUs of the future, but the world of video games is moving on. Many AAA titles being released this year requiring DirectX 10, which is programmable pipeline based, which is the equivalent to OpenGL 3.0 and above. The world is advancing to the point where the best studios use shaders to work with their game data. For someone to wants to work in the industry, I can’t bother with fixed pipelines anymore.

The best resource for learning modern OpenGL is the OpenGL Superbible in my opinion. The 5th edition of the book focuses on the programmable pipeline, but it has been criticized for using a helper library called GLTools for most of the book. This class encapsulates ideas like a camera, a graphics pipeline, and even emulates old-school fixed function concepts like the old glBegin() and glEnd() functions. This might not necessarily be a bad idea, but my problem with it is that the code itself is hard to work with. It builds but with a ton of build warnings because the author did not include any of the debug files with the library. The author supplied a Visual Studio 2010 solution file, but the files are arranged haphazardly inside it. Overall, I consider myself fairly competent in figuring out technical things, and this whole set felt very messy to me. For someone who is less experienced in the technical world, it may be enough to turn them off the book completely. Based on the reviews on Amazon, this is a very real problem.

The book never really breaks the reader completely free from the helper classes, which is unfortunate. It makes fully understanding some of these concepts harder than it seems it should be. In my own work in understanding OpenGL, I have started to slowly pull the code out of the GLTools library for the source code tutorials, so that instead of using those libraries I can actually see the OpenGL code instead. As I do this I’m going to post the source code and projects on the site here.

My impression of the book itself is that it is very good – Mr. Wright clearly knows a lot about OpenGL, and the book goes into details that no online tutorial I have seen covers. I think these topics are essential for anyone who wants to really understand how not only OpenGL but GPU hardware operates. But the code is just so hard to work with that I think posting a ‘translated’ version of it will be beneficial – certainly for me, and perhaps also for people looking to really understand the nuts and bolts of how OpenGL works.

It took me a LONG time to figure out how to do this in OpenGL 3.3. I found many tutorials online about how to do it in old school OpenGL, and I guess that’s becoming a more accepted modern way, but I didn’t want to do that. I’m really working on learning the mindset behind OpenGL 3+, and so I spent two days, but I got it working.

The basic idea is that the two buttons you see are each textures. I used GL_TEXTURE_RECTANGLE inside the glBindTexture() function so that I would be drawing in absolute window coordinates, rather than the typical GL_TEXTURE_2D that would give me a range of -1 to 1 in the x and y coordinates. That is probably not necessary, but made understanding the issue better. I also grabbed a shader from Chapter 7 of the SuperBible that translates the x and y values into 2D coordinates. That may not sound too coherent, but I haven’t spent much time with shaders yet, so I’m a little hazy on them still.

Currently, if I click on the OpenGL logo it exits the program. The Settings button (which is a .tga file, not a font – no fonts implemented yet) does nothing. My next plan is to have the buttons respond when the mouse moves over it, and have a state for clicking and releasing buttons. I have other versions of that Settings .tga so I can swap textures out when an action takes place.

Perhaps when I get this down a little better I will put a tutorial on OpenGL 3+ GUI programming. I’m sure people are looking for something like that. There are libraries online that will create pretty sophisticated GUIs, but I’m thrilled to have finished the basics of my own.

Here is the executable. Try it out!

GAM475 Demo

This project was created in five parts. The first part was the scene graph, which is just a node object that has a parent, child, and sibling. Make a ton of them and connect them all together and you have a tree. Professor Keenan gave us a bunch of unit tests that our tree had to pass and I was pretty surprised by how hard it was to make sure they all actually passed. But in the end we made a great scene graph.

The second part was a memory system, which was by far the hardest part of this whole thing. It was an elaborately debuggable system based on the Windows Heap API. Very complex, lots of pointer math, but I was so impressed by the whole concept that I’m going to do an independent study over the summer where I build a more in depth memory module for DePaul’s Azul project.

The third part was a file I/O system, which is currently just a simple Win32 wrapper. This was much simpler compared to the memory system.

The fourth part was the Math library, at least the Vector and Matrix portions of it. We are adding quaternions next quarter. This was more of an operator-overloading lesson for C++ than anything else. The math was pretty simple, but to get the operators to do what we wanted was harder.

The fifth part was the graphics system, where we took a simple OpenGL demo and built it into whatever we wanted. The requirements were to use the scene graph we made, cull objects against the camera frustum, and instantiate a bunch of our objects. It was hard because we were left to our devices to figure out how to do most of this stuff. Each week in class Prof. Keenan would go through the process of refactoring or building a small part of what we needed, but a bunch of it was left to us.

This proved to be a fascinating lesson. Rather than worry about finding The One Right Way to do something, as I used to do, I learned to just hack something together to get what I wanted, and then refactor the functioning code into a proper system. This is a much more effective and iterative way to get things done, and it was a lesson I don’t think I would be able to learn any other way. It was terrific.

So where to go from here? We have a number of steps we will be taking next quarter, but that doesn’t mean I intend to sit on my laurels in the meantime! I have four objects in the code as it stands – the pyramid, the cube, the doughnut, and an object that is essentially the parent that holds all 36 of those objects into a DNA shape. These represent four classes in my code. Each of these classes has a file for its overall representation or model, and a class that represents an instance of that object.

I want to abstract this into two classes. One will be the equivalent of Game Coding Complete’s Actor class – a generalized class that holds an OpenGL VBO with however many vertices this object needs, its location in the world, and anything else I may need for it. The other class will represent an instance of one of these objects.

In the end, this code will not function any differently, but internally it will be much simpler. It will also be more data-driven, as each of these objects will have a source file that its info is read from.

I hope to update here on a weekly basis of what I am changing in my system. As the months and years go by I hope to see it improve from what it is now to a fully realized game engine. I think even the next 10 weeks are going to show a drastic improvement.

When a programmer wants to create anything in OpenGL, from a vertex array object to a shader program, the proper course of creation is to define a GLuint ( which is just a typedef for an unsigned int ) which will serve as a label that connects your code to the object inside the OpenGL state. This is done because many of these objects are kept on the GPU, and so loading the data to the GPU is a different process than actually operating on the objects.

You use a call to define the label, and then use that label to load data into the OpenGL object. Once you get to the point where the label is no longer needed, you can actually delete the label. Deletion of the label is NOT the same thing as deletion of the object – in fact, OpenGL will hold onto information that it needs at a later time, so you don’t technically know when it is deleted.

That sounds a little abstract and crazy, so here’s an example for creating a shader. You initially call glCreateShader() to create a shader label, you send in the source code for your shader, and then, immediately after checking everything is okay, you can call glDeleteShader() to delete the shader label. The compiled code is still inside the OpenGL object, and will be used to transform your data, but the label is gone.

Of course, if you need to switch from shader to shader in your program, you don’t want to remove your one link to it. But you can if you don’t need it anymore.

VAOs serve as a batch of drawing commands. You can define a VAO, send in some drawing commands to set a particular state, and then in the future instead of calling those commands you can just set the VAO again. In my demo code I use separate VAOs for separate types of objects – lines, points, and triangles – and then bounce from VAO to VAO to draw them all.

VBOs are the buffers where you keep vertices and indices. This is where the actual tuples are kept. Many VBOs can be kept inside a VAO, along with instructions on how to use them.

I use gDEbugger to peek into how OpenGL is operating on my program. It’s a complex program with a TON of information – more than I really need at this point, but it’s been very insightful in showing how OpenGL states work, what is being stored in the GPU, and when objects can be safely destroyed. Best of all, it was currently made 100% free!

The goal of the project is to create a game engine that is accessible as the best possible learning tool for a budding game programmer. We have only had a couple basic meetings, but here is the basic idea. A game engine has many different moving parts – let’s generalize things and say it has an Input system, a File system, a Memory system, and so on.

Our goal is to make a 100% open source project that is built in terms of separate modules that can easily be pulled out. So if you’re interested in seeing how an Input system may look, you could come to our site and pull out the Input system by itself. Each individual system would have the library as it is used in Azul, as well as a sample Test solution that will be full of unit tests, so the person could see how those systems are tested.

I think this is a fascinating idea. My game engine course at DePaul has already won me over on Test-Driven Development this quarter, and Azul is helping me even more. As it stands, we are at such an early stage that much of my time is being spent thinking about the game architecture and how we want to structure things in general. I am busy reading up on several books on game engine design (and software architecture in general) and am finding the entire experience extremely educational. It gives me a chance to get involved in making some very big decisions about how to build a project, with the watchful way of Professor Ed Keenan giving us all guidance.

We are probably several months away from having something to show off, but that definitely doesn’t mean that no work is happening. On the contrary, there is a TON of work to be done. We have a game in mind as our goal, which will help drive us in a particular direction (and gives us a great end goal too). But as work happens, I will post here to update.

Needless to say, this also means my older game engines that I have written about here is moot for the time being. This is too good an opportunity to pass up.

void f() {}
 
int main()
{
     f();
     return 0;
}

In x64 disassembly, running in Debug mode, we get the following:

push rdi
sub rsp,20h
mov rdi,rsp
mov ecx,8
mov eax,0CCCCCCCCh
rep stos dword ptr [rdi]
 
call f ({address})
 
xor eax,eax
 
add rsp,20h
pop rdi
ret

Really this is mostly setup and teardown of the main() function – the only line that refers to the function call is the actual call f ({address}) line, where the number in {address} will be different depending on where Windows put your program in memory.

This is obviously as simple as it gets, but what happens if we switch this to a Release version?

xor eax,eax

That’s it. Not even the setup and teardown of the main function!!!

This happens because the Visual Studio compiler is optimizing away everything that is unnecessary for the program to run. By looking at this extremely basic source code, it sees the following:

The f() function is unnecessary because it doesn’t actually do anything. So we aren’t going to call it at all.

In fact, the only thing the entire program does is returns 0! So instead of even setting up the main function, all we need to do is put a 0 in the eax register, which, as you know, is where the return value of any function is placed. So the entire program has gone from the 11 lines in the Debug version (really more, as the rep stos command is a loop in disguise), to a single xor in the Release version.

This is great when you are programming a game, as it saves a lot of real time in your Release version. But… what if you really wanted to ensure that something is NOT optimized away?

The general answer to this is the volatile keyword. This keyword, when applied to a variable, tells the program that it is possible for this variable to be adjusted by a program outside of this one. In other words, the compiler can never assume it holds the same value it held the last time you read it, so you can never optimize any reads away.

So let’s stick that in here.

volatile int a = 5;
 
void f() { a++; }
 
int main()
{
    f();
 
    return 0;
}

Notice that we are now incrementing this volatile int inside of the f() function. This should do it right?

Well, let’s take a peek at what we have now:

inc dword ptr [a ({address})]
xor eax,eax

Well, we’re partly there. The inc instruction is what increments that volatile int, but it has still optimized out the function call and just increments it in the main function. This is a sign of just how smart the optimizer in Visual Studio is.

We would have to make some more complicated code to keep the function call inside main(), but this should be enough to show how important using volatile can be when you absolutely need to see some assembly code in your Release version.