Math library; Core Engine development;

Even if I am not coding really fast, I'm studying different topics in which I find really different 'formae mentis': this is really fascinating!

Actually I written a non-template version of my math library, with some basic support for SSE/VMX code: premature optimization is the root of all evil.
So I'm moving forward to implement other core part of Hydra: camera, input and debug output!
Actually the camera is almost done, with all the code (like plane extraction, frustum vertex in world/view-space) working, the input is almost done and I'm writing the implementation of a directx9-based renderer, that will be used right now only for debug graphics to test that everything with maths works!

Also, I bumped in the Function Pointers World...really fascinating, with simple code that can make you skip some branch to choose what to do on different situations and have some performance gains...
I'll try to use them in the core part of the engine, to avoid virtual keyword and to skip some branches; this engine is not a commercial-one, so I am free to experiment everything keep my attention!

Small snippets

There are small snippets that can be used very well...
One is a simple software interrupt:

__asm int 3;

The second is more evolved, but if used correctly can wield to know everything about your code:

#define Stringize( L ) #L
#define MakeString( M, L ) M(L)
#define $Line MakeString( Stringize, __LINE__ )
#define Reminder __FILE__ "(" $Line ") : Reminder: "

so if you use the #pragma comment (Reminder ": TODO/HACK/FIXME") under MSVC compilers you will see the message in the output window, and with a double-click on it, you'll be teleported on where the code is written, so you can keep track of all the stuff you have to change...during compilation time!

Really useful, small and smart ;)

P.S. A really simple profiler is born, now I'm writing my math library from scratch, so to see some eye-candy you have to wait some days!
Next steps include:

• Basic math library (with future support for SSE)
• Input handling (mouse, keyboard)
• Camera and Frustum classes
• Debug draw (lines, spheres, cubes)
• System coherence tests (project/unproject, world/view/screen space tests)

In the meantime I'm designing the structure of the engine with all its new systems/parts, and after those steps I'll began coding all of that!

Stay tuned ;)

Math-o-centric view

One of the thousands of changes I'm doing in the new Hydra is the math system: my math always based on a template math library without any SSE-kind optimization.
I went into a journey that highlighted the lack of centrality of math code and the lack of SSE.
Is it really necessary to use SSE?
The real advantage of SSE is the use of instructions that works on 128-bit registers, and that can contains, for example, a 4d vector.
The BIG advantage of SSE is to use the mentality used when writing shaders to reorganize data in
Structures Of Array and gain a near 4x speedup!
After some study, I've decided so far to eliminate the template aspect of the math library: floating points is the standard de-facto. The real twist is the centrality of math: to use SSE, it is better to create a place in which all math is done; this ensure the possibility to apply different kind of math calculations (better for multiplatform development) without changing code outside the math system.
I think THIS will be the real power of the new design: all math inside the proper system!
After that big change, SSE optimization is a matter of time.
For example, Frustum Culling: imagine a method that performs a Frustum-AABB intersection

int Camera::intersectAABB(const AxisAlignedBox3f* const aabb)

even if it can be cool to let the camera calculate the intersection (by information expert, it can be either the Camera or the AABB), it is smarter to move this method in the math system, like that:

int Math::FrustumAABBIntersection(const AxisAlignedBox3& aabb, const Frustum& frustum)

this assure that if you want to implement different math (SSE/VMX/SPU-like) you can do it using the preprocessor.

I'll try this different approach, and profile the changes from template-based-sparse to float-centric math, and also to float-centric-sse-math.
I am really CURIOUS about the results!

Stay tuned, next time I'll post some timing and talk about the Core of the Engine!