Reversed Normal

… Not really.  As much as I wish this was all some hallucination, I am in fact in the Wichita airport, tired and an hour away from a flight to Dallas, followed by a flight to Atlanta, and topped off with a 3 1/2 hour drive to Savannah.  Somebody shoot me. 

Time spent with the family is totally worth the trip, though.  I so rarely see my folks anymore, and it’s nice to be fed and to load up on books and nice things to wear.  It has been snowing in Kansas; something that is still novel to me.  In the South, we believe ‘hard water’ is a man-created thing, fashioned out of the need to cool one’s beer, and certainly not something that simply falls from the sky.  Dad apparently drove into a snow drift the other day and had to be dislodged by a better equipped passerby.  He claimed he had been caught in a ‘white out’ of arctic magnitude - three meters from the Target entrance.  Okay, Dad. 

I’m very much looking forward to being home again, and to picking up Iterator from the kitty hotel.  I have a few days before the other half of my family arrives for New Years. 

There are still some rather large loose ends I need to tie up after the work Dave and I did on the code base.  The new background loading system which we implemented has opened a whole new can of worms.  As it turns out, the Windows OpenGL implementation’s rendering context is thread locked.  When a scene is loaded in the background, it has to initialize new textures and VBOs with the rendering context, which belongs to the rendering thread.  This means that I’ll either have to switch ownership of the context between threads when something is loading (bad) or defer initialization of OpenGL dependent objects (meshes and materials) and load them in the rendering thread when it isn’t rendering (also bad).  This is all really dumb.  When writing this kind of thing on the Mac, you can manipulate a GL context from whatever threads you want, provided you set up your critical sections correctly.  Windows is dumb. 

On the plus side, I’ve refactored each class’s Lua initialization code to register with the script system using a pre-main initializer, and have rearranged things such that each new Actor instance has its own Lua state, which shares a global table with the script system’s main Lua state.  Prior to this, I had a single global Lua state which was shared by all Actor instances.  This fixes a problem I was running into when trying to add new Actors (and their scripts) in a background thread using the same Lua state being executed in another thread.  Only one Lua state per thread.  Always. 

Enough rambling.  I have a plane to catch.  See you in Savannah!! 

The difference between a good programmer and a mediocre one is the good programmer has seen more errors and fixed more problems than the mediocre one. With this in mind, I’m going to start a segment on my blog where in I will share some of the little things I’ve picked up in hopes it will save someone out there some time. I haven’t come up with a clever title for this yet, but when I do, I’ll let you know.

So let’s get started! Today, I’d like to share with you a little trick I picked up from David Eberly’s books. This tidbit deals with pre-main static initialization in C++.

The Problem:

When you create several static variables or class members in C++, there is no guarantee as to the order in which C++ will initialize their values. Let’s say you have a vector class. You’ve defined a static member somewhere in your vector class called UNIT_X, which is the unit vector along the X axis. Somewhere else in your code, you want to initialize another static vector called sMyUnitX to UNIT_X. This doesn’t present a problem if UNIT_X is initialized first, but because there is no way of knowing which static variable C++ will initialize first, there could arise a situation where the sMyUnitX is initialized before UNIT_X, in which case, sMyUnitX will be filled with zeros instead of the unit vector like it should be.

Solution:

The solution is to somehow defer the initialization of sMyUnitX until after we’ve entered main, thus insuring UNIT_X has been initialized before we assign its value to sMyUnitX. To accomplish this, we’ll create a class called Main. Main will have two static methods: Main::Initialize() and Main::Terminate(), and will store an array of initializer and terminator function pointers. Here’s the class:

(Note: WordPress is dumb, and won’t let me put less than or greater than signs in my code without thinking it’s another tag. Those two Array variables down there are supposed to be templates of type Initializer and Terminator)

(Another note: Would somebody please tell me how to get WordPress to retain code indentions?)

Main holds two arrays of function pointers. All of the initializers are called when Main::Initialize() is called, and all of the terminator functions are called when Main::Terminate() is called. Here’s what your main function should look like:

This is cool and all, but how do we set the initializers and terminators in the first place? That obviously must be done pre-main. There is no way to explicitly tell C++ to execute code pre-main. All C++ will do is initialize static variables. We can however include a function call as part of a static variable’s initialization, thus forcing C++ to call a function pre-main.

We’ll exploit this little trick and build three preprocessor macros for registering initializers and terminators with Main. Here are the macros for registering initializers:

The DECLARE_INITIALIZER macro goes in your class definition somewhere, and sets up the function Initialize(), in which you will put any static initialization you need to defer to post-main, the function RegisterInitialize() which is responsible for adding a pointer to Initialize to Main, and a bool to make sure we don’t initialize twice. The IMPLEMENT_INITIALIZER macro implements the RegisterInitialize() function, and should go in your .cpp file somewhere. The REGISTER_INITIALIZER macro goes in your .h file outside of your class definition, and by using the little pre-main function call trick discussed earlier, actually called the RegisterInitializer() method.

For clarification, here is where the macros go:

That’s it for now!

So I’m on MobyGames.com the other day looking somebody up, and decided to check in on my profile to you know, make sure it was still there. As it turns out, I got a credit on Guitar Hero Encore: Rock the 80s! A pleasant surprise, considering I had nothing to do with 80s. I’ll take what I can get, though.

Also something which might be a pleasant surprise to some, Buck, Fic and I recorded a brand new podcast this evening. Episode 33 is special because as one listener’s feedback pointed out, 33 was the last show we did for IMG with Big Tuncer, after which we left and made BDPE, which is invitingly cooler. Rest easy, dear listeners. We’re here to stay.

No, I’m afraid not.  If he did though, it would be as bleak.  Seriously, I’ll get around to skinning this thing nice and pretty.  I won’t let four years of art school go to waste.  Until then, I invite all to revel in my blog’s zen-ness.

So I’ve got one of these blog things now.  I resisted for so long, but when it comes down to it, I really just want to fit in.  This kind of thing is what happens when all my friends leave, and I start drinking alone in my room.  I blame you Dave.