Nova’s Achilles heel
Nova’s Achilles heel is the math and a lot needs to be improved there. Instead of attempting to improve I thought I would use a high quality math library instead (in this case vmmlib). Using SVN external I added it so that it would automatically fetch the latest version from their SVN and be done with it. Problem is that I’m using DirectX which uses row major matrices and vmmlib was written to be used with OpenGL which uses column major matrices. So after a huge rewrite and removing the old math headers I tried to run Brick and see if it worked, I had hoped that by setting the effect files to use column major matrices I would let it use one system. Seeing the result, it either didn’t work or something else had gone wrong.
I don’t know what exactly went wrong (besides the obvious) but I guess that instead of using another library I just have to finish and improve my own math library. It’s a good thing SVN allows me to revert. 
A good math library is essential for a game developer. It has to be easy to use and clear but I also want answers on the following questions when I’m using it:
- When I define a quaternion is it written as W-X-Y-Z or as X-Y-Z-W?
- Does a multiplication operator between two matrices do a matrix multiplication or an unit multiplication?
- Also how safe are the functions?
- How do I prevent hidden cost?
- And how easy is it to cast from one to another? Vector3<float> to Vector3<int> might seems obvious but it requires code to support it. And I could also cast Vector3 to Vector2.
Then there are the bigger question about optimization, like do we use SIMD or not.
The biggest problem is of course to ensure that all math is correct. Most of the time I use it by instinct, but in this case I actually have to relearn all the math again, double check, ensure that I’m using the right version, triple check. Obviously I experience it as a pain, but it as they say:
No pain, no gain!
Smart pointers: A dumb idea?
A while ago I wrote a smart pointer for Nova and I have been wondering on whether or not I should use it. And if I did choose to use it to what degree.
Smart pointers are useful, I use the boost variant often enough, but like everything you shouldn’t fully depend on it. Pointers are in many cases good enough. The only thing why smart pointers are so useful is that you don’t have to worry about the lifetime of the object (when the object is destroyed).
In many cases the only time you worry about is when data needs to be shared, for example a texture, as you don’t want to load the same data twice. But another simple technique is the IUnknown interface which creates an object that will delete itself when it has been released as many times as it was created. You still don’t have to worry about the lifetime of the object, you only have to remind you to call release when you no longer need an object. If nothing requires that object the call to release will cause it to delete itself.
Here is the basic code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | /* IBaseObject.h */ class IBaseObject{ private: unsigned int m_ReferenceCounter; protected: IBaseObject(); public: virtual ~IBaseObject() = 0; unsigned int AddRef(); unsigned int Release(); }; /* IBaseObject.cpp */ #include "IBaseObject.h" IBaseObject::IBaseObject() : m_ReferenceCounter(1) { } IBaseObject::~IBaseObject() {} unsigned int IBaseObject::AddRef(){ return ++m_ReferenceCounter; } unsigned int IBaseObject::Release() { --m_ReferenceCounter; if(m_ReferenceCounter == 0) { delete this; } return m_ReferenceCounter; } |
After some thought on the issue I have decided that IUnknown is far superior to a smart pointer. The majority of the smart pointers I have encountered and written work on the same basic principle. Each smart pointer has a pointer to the object and also a pointer to an integer in which you store the amount of copies. That means that if you look at the code it will look something like this:
1 2 3 4 5 6 | template <typename T> class smart_ptr { T* m_Data; unsigned int* m_Copies; }; |
When you think about how smart_ptr really works, you will think how stupid the idea is. For every copy of the object you will have two extra pointers, assuming 32 bit system, that would be 8 bytes extra for every copy.
The second issue is a bit more hidden but if you have this function:
1 2 | class CObject; // Just an object void accidental_copy(smart_ptr<CObject> copyParam) { /** does something **/ } |
You will be making an copy of the object, which means that you will have an extra construct and destruct function to take in account. Which means that a smart pointer not only increases the amount of memory needed, but also reduces the speed. With a pointer you won't have the above problems.
There is however one huge advantage that a smart pointer has but IUnknown doesn't: Smart pointers can work with virtually any type while to use IUnknown the object needs to be derived from it. However since I'm writing the code for Nova I can just make sure that all objects derive from IUnknown.
To add an conclusion, I have decided to before using smart pointers I should first try and see if there is another solution.
Nova – Alpha 1
I have given Nova, my graphics engine, a milestone named “Alpha 1”. This means that the engine will need to fulfill certain conditions at a certain time.
The good news is that I might release it to the public for free (including source) if I find the quality good enough.
I have been using Nova for quite sometime now for my graduation project and except for a few small issues (the math part is not to my liking) I have absolute no issues with it. This is rare since I tend to over criticize my work (I once argued with my teacher after getting the highest possible score because I felt the need to point out the mistakes I made).
If your expecting a fully fledged engine with scene graphs, model loaders and million of other features I think I will have to disappoint you. Nova was intended to be an engine that was in the first place easy to use and in the second place was flexible. At the current state it is a perfect engine for rapid prototyping and highly specialized low level work. But that might change with later iterations. After all this is only the first release (an alpha to boot).
Anyway I will post more information about the possible release over time. The milestone for now has been set on 1 may of 2010.