Indie::Game::Dev
C++ Constructor Confusion
by Cristian Sandu on Dec.02, 2009, under EnLight3D
I never got a chance to finish my implementation of GLSL hardware shadow mapping two years ago when I built my EnLight engine and I’ve been struggling with the idea of starting work on it again but somehow between work and everything else in two whole years I haven’t written a single line of code towards that goal. I did however implement something in Cg in my engine but that was for a different project.
Anyway…having some time on my hands I’ve built my compile environment and was ready to start working on it a bit when I discovered that after recompiling, now that I had upgraded to Visual Studio 2008 – and a new compiler, my old demos would fail. After some brief debugging I came to the conclusion that I had made an odd mistake.
Here’s the deal, from my time in school I clearly recalled that C++ constructors can be called like any other function – there are many reasons why C++ allows this but I won’t get into it. This, in the hands of someone who, like me, has worked with other OO languages like Java and C# can be lethal. While in Java and C# it’s perfectly healthy for one constructor to call another constructor of the same class to do some initialization, in C++ things tend to get quite perverted. You see, I had used this mechanism(which I thought worked) to call from a more complex constructor the basic constructor to set may member variables to default values.
So, my old code was like this:
GLSLProgram::GLSLProgram() : m_vsHandle(0), m_fsHandle(0), m_progHandle(0), m_inUse(false) { } GLSLProgram::GLSLProgram(File* sourceVS, File* sourceFS) { GLSLProgram(); (void)this->Load(sourceVS, sourceFS); }
In my ignorance I thought this did the following: construct my object, call the basic no args constructor and initialize my members to zero and then continue with the rest of my constructor code. What really happened was this: the object was indeed constructed but the constructor call from within the constructor created another object which it initialized and then destroyed as it exited the call. Strangely enough this “worked” with VS 2005′s cl compiler and gcc for windows from the mingw package. What probably happened was that my member variables were initialized to 0 by the compiler anyway and I didn’t realize what happened. VS 2008(well, the cl compiler in VS 2008) seems more unforgiving and more strict initializing my variables (and these are pointers!) to random numbers to teach me a lesson that I will not soon forget.
To fix my code, I did this:
GLSLProgram::GLSLProgram(File* sourceVS = 0, File* sourceFS = 0) : m_vsHandle(0), m_fsHandle(0), m_progHandle(0), m_inUse(false) { if (sourceVS || sourceFS) { (void)this->Load(sourceVS, sourceFS); } }
As you can see, I used the old default parameter values trick C++ has up its sleeve. While this is regarded as dangerous by some developers I find it useful as an alternative to function overloading. Sure, fancier languages like Java and C# have dropped this feature forcing developers to use proper overloading but C++, like the old saying goes, lets you shoot yourself in the foot. It’s actually funny to have code that is legal but useless.
That’s C++ for you, always with the hidden jokes
.
Working the Ol’ Engine
by Cristian Sandu on Mar.28, 2008, under EnLight3D, Indie::Game::Dev
[From EnLight 3D blog]
I’ve been slowly doing some work on the engine; nothing impressive so far.Added nVidia Cg support for shading.In the mean time I thought I’d upload one of my old videos. This is something I cooked up in Bryce, 7 or maybe 8 years ago. It took me 6 hours to render it on my Celeron 300
. It’s not much, but I remember being very proud of it.
Also, here’s one of my early EnLight 3D demos running in Windows Vista.
Look Ma, I’ve Got Limbs!
by Cristian Sandu on Jan.20, 2008, under Indie::Game::Dev
[From EnLight 3D blog]
Not sure I am very satisfied of how the little dude looks, but this what I have so far:
A Head in a Blender
by Cristian Sandu on Jan.13, 2008, under Indie::Game::Dev
[From EnLight 3D blog]
Well, I’ve started messing around with Blender(following a tutorial) and trying to make a character for my project. This is what I got so far. Luckily, it has to be a funny character.
The Demos
by Cristian Sandu on Jul.12, 2007, under Demos, EnLight3D
[Imported from the EnLight 3D blog]
Here are the promised Win32 and Linux demos. Game resources were not included. You need a Quake 3 Arena CD/installation from which you will have to extract(from pak0.pk3 – which is in fact a zip) the following directories: textures, scripts and models to the ‘demos’ directory. I cannot provide these files as it would result in copyright infringement. The Win32 demos also use the MinGW runtime which is provided.The demos use the wxWidgets framework libraries which are statically linked in. Get all the archives here.
The Park
by Cristian Sandu on Jul.12, 2007, under Demos, Indie::Game::Dev
[Content also imported from my EnLight 3D blog ]
This is a an older project of mine. It contains a water simulation. Not very advanced as you will see but it was an important step for me at the time. To see it, u need to go the well in the scene and click on the water surface to generate waves. It also has support for shadow mapping(not very pretty), but it is disabled by default, to re-enable it use the right click pop-up menu. The various keys used are described in the readme file. No source code, just the executable.
The archive can be downloaded here.
The First Release of EnLight 3D!
by Cristian Sandu on Jul.11, 2007, under EnLight3D, Indie::Game::Dev
[Content was imported from my EnLight 3D blog]
EnLight 3D was my graduate diploma project at my university. Its objective was to be an all-purpose 3D engine. However, it is my belief that I have achieved only 70% of the required functionality of a modern 3D engine. Therefore I will not release any source code at this point, only a few demos, to give you an idea of what the engine is capable of at version 0.7.
One particular aspect that requires a lot of work is that of lighting. A dynamic and more realistic model needs to be implemented. Also I am thinking of adding support for Doom 3 levels. After all, this is one of the engines most used today and for which good level editors exist. At this point the engine offers support for Quake 3 .bsp and animated .md3. 3DS objects support is easy to add, as I have done this in a previous project and all I have to do is migrate the code. The engine also supports collision detection based on the bsp tree.
I will post some Windows and Linux demos shortly. Also, a stripped down version of the doxygen docs can be found here(10 MB quota prevented me from including any cool graphviz diagrams, all descriptions are in Romanian
).
Here’s a video of an EnLight 3D engine demo running on Windows Vista.(Not actual speed – slowed down by recording software)


