Development notes

I've had a pretty good smart pointer going for a while in my C++ projects. The pointer consists of two main classes. The template class that you assign your objects to and a baseclass that this template derives from. The baseclass stores a static multimap of all the objects and which pointers are pointing to them (object->pointer).

It stored the objects simply as a void* and compared the addresses of the objects to decide if they were in fact the same object. By doing this, the pointers could drop an object and let every other pointer pointing to the same object know if they still pointed to something valid or not. It could also just let all the pointers go out of scope and automatically clean up the dangling object when the last pointer was destroyed.

Oh it was green hills and lush forests until the beast that is multiple inheritance came along. Using the pointers on base classes hadn't been a problem before. It would still realize that it was the same object. After a good debug run, I realized that the same object gave off two different addresses!

Subobjects

C++ figures out that these guys in fact belong to the same object even though they can have a different address, as long as you keep the type pointer. If you for some reason, like casting to a void*, lose the type, it can no longer relate a subobject's address to it's actual full object.

My instinct was to not let the type go away. Templates must be the solution I though. I made a baseclass that would virtually pass along the comparison needed to a templated subclass where the type was stored. I tangled with the code for hours trying to get the templates to compare directly to each other. Unfortunately, templating doesn't work on virtual functions, neither at the base nor the derived. So I was at a loss I thought, and started considering living with it and simply avoid using multiple inheritance. 

I took a break and relaxed, which I should've done hours earlier. Things have a tendency of clearing up when you stop thinking about them so intensely.

The wrong Solution

So it suddenly struck me! I actually only need ONE of the types directly to figure it out. To sort the multimap, the operator < is used. I was stuck with using void* < void* or just static_cast<T*>(voidPointer) < voidPointer2, which gave the same result. But naturally, the objects does have a size, and I know that size if I know it's type and can then check if an address lies within the object! If it does, it's the same object.

So the sollution in short: (char*)voidPointer+sizeof(T) <= voidPointer2

Casting to a char* gives the object a size of basic machine units, which is 8bits, or 1 byte. A void* has no size and sizeof returns the size in machine units. This result in the address past the end of the object. So to compare an object as being greater than this object, it must be allowed to begin at the past end address, hence the less or equal operator. I also defined the operator > which just tests the addresses plainly. When the actual comparison is made by the baseclass, it uses both comparisons, since it will give different results if the subobject or the "root" address is on the left side. So the return looks like: Address1 < Address2 && Address2 > Address1

The final solution (a month later)

There was one single case where the old solution didn't work. Comparing two subobjects of the same complete object didn't result in equality, since the two subobjects didn't overlap (address+size).

I once again went on to find a better solution. I knew that the vtable of a subobject kept an offset to the complete object, but there was no obvious way of reaching it. Hacking the vtable is a bad idea and is highly implementation dependent.

I finally gave up in figuring it out myself and consulted the good people at stack overflow. The answer was so simple that I could barely believe it.

dynamic_cast can actually give you the address to the most derived, the complete object, by using it with void*: dynamic_cast<void*>(mySubObject)

This simple realization let me clean out my complex templated address class and simply cast to void* and make a straight comparison to establish object identity.

I must say that this could have been mentioned with an extra sentence on cplusplus.com.

As always, OpenGL is really obvious once you figure it out. I've mentioned one before, and today I stumbled into another problem that just seemed so weird but so blatantly dumb when I found the solution.

While implementing a framebuffer object to give my upcoming sprite library some handy resolution options, all my projections got thrown off when I made the framebuffer smaller than the window. The basic setup is to render all sprites to the framebuffer first and then resize it to the requested pixel size in to the window. Resolutions still smaller than the window would feature a nice black border to leave the pixels at the desired size. But when I tried the smaller resolutions, the origo was thrown off and the pixel changed to non-specified sizes! The smaller I made it, the bigger the pixels and farther the origo went.

I figured it had something to do with my projection matrix, which was simply orthogonal to fit the pixels of the framebuffer. Well, no luck there, and a good bit of experimenting was done before that conclusion.

Finally, I came to realize, that the width of the smaller frame buffer isn't scaled properly via the viewport! The projection is suppose to normalize the values to the ranges -1 to 1 in both x and y-axis, and then the viewport translates it into pixel positions. So by re-sizing the framebuffer, without updating the viewport, the origo and scale of everything drawn was skewed to the lower left corner!

So the solution was simple enough! Use the glViewport to specify the size of the buffer you're rendering to, each time you switch! If you happen to use two render buffers of different sizes, you better keep track of this to not get damn confused about what's going on with your projections.

OpenGL can sure throw you a few unintentional curve balls. As I was trying to pass a uint with different bit flags to a shader, I couldn't figure out why the uint I passed was scrambled in the shader. I checked the whole buffer setup and the attribute pointers, but was completely lost and wasted a good bit of time on this.

Funny thing is that I've already done this once in the same piece of code and I ran around trying to find the fault then too. Turns out there's too attribute pointer functions.

glVertexAttribPointer(...) glVertexAttribIPointer(...) 

Easy enough to miss on a glance, and even trickier to remember until you've been burned (a few times?). You'd think, since the glVertexAttribPointer takes an argument for what type of value should be passed to it, it's all right to give it one of the integer types GL_UNSIGNED_INT or GL_INT and then send your int down that line. For some reason, they're accepted in the non-I version of the function, and doesn't complain about it at all, but they're somehow implicitly cast (not converted) into a float and back again when passed to the shader from the vertex buffer. They don't care to say why you'd want to pass an int to that function version in the documentation either.

It's not the most complicated thing to figure out, but it can get you running in circles for a bit if you're new to qmake.

I like having a console window to debug with, which qmake doesn't enable by default. The documentation isn't great on explaining it, so here's what to do:

Generate a project file with:

> qmake -project

Then open up the generated .pro file with a text editor. It'll be partly filled in by qmake already. Here's the lines you need, some of which may already be in the file:

TEMPLATE = app CONFIG += console DEFINES += WIN32 _CONSOLE

Qt is a beast! It's huge and kind of bulky, though it seems pretty good to work with once you get going with it.

Setting it up wasn't the easiest task and I did make a few mistakes before it started to give a pulse. First off, I tried downloading the first option from their site: The QtSDK installer.

It didn't really have any support for visual studio, let alone vs2010. Took me a while to figure out that I hadn't made the right choice. What should've tipped me off was that most stuff was put in a folder called "symbian", which most of you probably know is an OS for smaller devices.

After some digging, I decided to download the source code version for vs2008, as the vs2010 was missing. I almost got up to speed following these instructions in their documentation. Trying to compile my test code, qmake worked, and nmake performed the compilation without complaints, but when I tried to start the resulting .exe file it refused to start, with the error:

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Digging around, I found out that it was trying to use the VC90 debug libraries, instead of VC100 which VS2010 uses. I was pretty sure the Qt/configure.exe detected the msvc2010 setup, but still no go.

So my search went on and I found another instruction, although unofficial. How to compile Qt 4.7 with Visual Studio 2010 sounds pretty darn specific, so I figured I'd give it a shot. It warns that compilation can take up to 10 hours, and I'm waiting for it to complete as I write this. With jom, an nmake clone that uses multicore better, it's suppose to take under 3 hours. I sure hope that's the case!

To be continued, when the compilation is completed.

1 hour later: