What’s up everyone. I told you I’d be doing posts! Luckily for you and me, I actually have to do this for my class. It’s a grade. My group and I all have to do individual, weekly posts. I will be posting these posts on that site as well as this site. If you want to see my other team member’s posts, click here.

Like I said in my last post talking about RTA, I tried to create some initial architecture for my engine even though I mainly created the renderer portion of the engine. It could do smooth skinned animations, blending, and some other things. I tried my best to make it where I could easily make a game engine out of all the code I had from RTA, but I still had to do some things to get it up to the point where I could use it in a game engine. That’s what I did during my first week of working on the Extinguish engine.

One of the things that I didn’t like about my old code was that I had dozens of lines loading in shaders and creating them. Luckily, my RTA teacher had a powerpoint showing how we could load in the .cso files, that were compiled from the .hlsl, really easily. This, along with some of my previous knowledge, allowed me to write a single function that would load in every single shader ever dynamically. I did this by using some WIN interface that allowed me to look for all the .cso files in a certain folder. Oh, I forgot to mention that I did this all in the resource manager, which is something I started implementing over the winter break.

The resource manager’s job is to have all of the Directx11 objects, meshes, etc. loaded in and created, and then whenever I need that thing, I ask the manager to give me it. This was to make my renderer more modular because I previously made my renderer make several different objects itself. My RTA teacher noticed this and told me I should separate this, and I did.

Another thing I had to finish this week, which I also started to implement over the winter break, was a component based engine. This was something I asked my RTA teacher, Mike Lebo, about last month: should I make a component based system or should I make a system based off of inheritance. Alright, I don’t know what type of system the latter one is, but it’s one where you create a class for each type of game object you want. So you would have this base game object, and if you wanted an animated game object, you’d inherit from the base object to create an animated game object. If you wanted a game object with a transform, you’d derive from the base game object to create a game object with a transform. If you wanted an animated game object with a transform, you’d derive from both the animated game object and the transform game object. As you can see, this seems like a pain in the ass.

Maybe it works out in the end because Mike said that both systems have pros and cons, but with my familiarity of Unity, I thought a component based system would work better: have a game object that has a vector of components. The component would be a base object, and whenever you wanted to add a feature to a game object, like a transform, renderer, or physics, you’d derive from the component to create that new feature.

So that’s what I started over the break—I made the component class, which had three virtual functions: Init, Update, and Shutdown—and I had to make the renderer from last month into a component that would be attached unto a game object. Then I also had to make a transform component that would contain local and world matrices, along with a parent pointer, sibling pointer, and child pointer.

The coolest thing about the transform is that if we have a character and then a lacrosse stick, both separate from each other, the transform class will really help us connect the two. What we’d do is set the child of the character’s transform to the lacrosse stick, and the parent of the lacrosse stick would be the character. So that way, when the character moves, the lacrosse stick moves. This is done through some math: the world matrix of the lacrosse stick is equal to its local matrix multiplied by the parent’s world matrix.

What’s interesting about this whole process is you only do this math if the node bDirty and that transform has a parent. What do I mean by dirty? Well, say the character is still. The world matrix of the lacrosse stick doesn’t need to change. So I wouldn’t need to do any math to update the world. Now, if the character does move, I would need to update any of its children. I do this through a recursive BDirty function. The interesting part is that I set it to bDirty instead of just updating the world matrix right away. This is because I only actually do the math when I want the world of that transform. This way if I were to mark the transform to bDirty 1,000,000 times, but I didn’t want that transform’s world matrix until the 1,000,001th time, then I just saved a whole lot of calculations.

But yeah, that’s it for me this week. Next week I want to fix my input manager and start messing around with controlling a lacrosse stick.