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!

Starting from scratch...again?

One of the most intriguing aspect of the game development is the tendency to hide the knowledge.
This is one of the most stupid thing that we human can do: hide our knowledge.
Why that?
Lack of self-confidence, company ripoff of staffs, and many others...I think it would be very useful to study some System Engineering and Systems in general.
Maybe a lecture like 'The web of life' could be REALLY USEFUL.
Sharing of knowledge let other people to improve what you are working on: think of the open source.
One day...the gaming industry will be more open, and maybe not every company will start its own engine because it has no money to buy one! :P

Sorry for the rant...but I like sharing ALL, because I find that everybody can learn you something, even a 'negative person': it teach you what NOT TO DO!

Apart from that...I've started rewritting the engine, to go multithreading and to apply all the knowledge I'm building now. Nothing more than an engine to understand the base of all the game development and to experiment new things...
The third iteration of Hydra (codenamed 'Turgid') will be available also on SourceForge.
I'm pretty excited about it, because I can concentrate on different aspects every time!
The first iteration was about...EVERYTHING! Two years ago, I've know nothing about game engine programming. So I studied all from scratch, trying to create a base renderer.
The second was about shaders: I wanted to develop and to investigate the beautiful world of shaders! It ended in a Light-PrePass renderer with shadow maps, screen space ambient occlusion, lightshafts, hdr...many interesting things!
What about the third? I want to enter the multithreading world, I'm really fascinated about it. Also, I want to extend the engine to became a more robust and complete framework, including also a small editor, some physics, AI and sound! And...continue studying special effects, shaders, DirectX11...
The last thought about the third iteration is about the multi-platform development: the actual design had taken in account the possibility to use OpenGL and to run under Linux and MacOS; about this...time will tell!
I want to update this blog more frequently and take many screenshot of the work in progress...

Stay tuned!

Moving forward: Portals, DX10, Multithreading!

REALLY busy time, luckly!
We are working hard and beautifully in my company...we are experimenting and learning new things, so it is a great time!
In my spare time, apart from learning playing flamenco and jazz, going gym, reading many books (Robbins, Dills, Dyer...) , I'm studying some interesting things: Portals, Dx10 and Multithreading!
Currently I'm implementing a simple Portal System, and designing a completely rewritten game engine that takes in account the multithreading as the base brick of all the structure...this is really fascinating, because nowadays most applications are single threaded and the multithreading is added AFTER the creation of the project.
I've installed Windows 7 on my laptop, and I have to admit that it seems a good operative system: vista-eye-candy, nearxp performance. That unlocked the doors to Directx10, with all the goodies that cames from...the Directx11 also can be used, but on a Geforce8600m gt there is no room for that!
So basically...time to study. Hope to post some screenshots of the portal system soon!

SSAO!

After some fights...here comes the SSAO!


This is the beauty of the 'waterfall effect' of the deferred/lightprepass/z-based rendering: one you have coherence between different spaces (world, view, projection, texture...) and you switch between them rather easily, you can begin working on many interesting effects :)
This is a real basic implementation, based on various post on gamedev (thanks guys!!!)

Finally a new connection!

Long time no see guys!
This is the first day I have an internet connection in my new house. After 3 months actually!
I was really busy at work, but I continued programming.
My new challange is the Deferred Rendering...a real cute rendering architecture!
After many reads (mainly gamedev) I moved to my first implementation: I found really useful to do all the calculations in view space, the view space pixel position reconstruction became really simple.
Also, the G-Buffer is actually composed of only 2 render target, rendered with a MRT: normal and linear depth. The result is a Light-Pre-Pass-Like renderer...I'll show a little result:

10 pointlights on the screen with the known rockwall normal map.
I'm also working on the ScreenSpaceAmbientOcclusion so I can move to create a little demo.
Stay tuned!

Actual State; Near future; Future;

Some changes have happened in the last month.
I changed city, company, life.
I moved 700km away from my home, in a more prolific environment and with cool guys.
This is the main reason of the slowdown of the blog!

I'm actually coding hard, because I want to study some topics in which I'm weak, and then I want to merge all of them in the new Hydra!
During these days I'm creating some really small demos that covers different aspects of game programming:

- GUI and Font handling;
- Animation;
- Collada import;
- New graphic pipeline;
- Lightmapping;

These different topics are really interesting, and I'm quite happy of the results.
GUI and Font handling it is something simple, but can give you satisfaction and OUTPUT.
Animation is a really tricky topic, I've done a small exporter in maxscript and all sounds good,
but then I've read this article (link) and found that an importing pipeline is a good choice, even if more difficult for some aspects! Then I began using Collada...really good and FREE.

New graphic pipeline. I wanted something more shader-oriented than before, so I switched to Cg...really COOL! The rendering is organized in pipelines...each one has its own stages. Every stages can specify one or more render target and all the textures produced are specified in a common pool of texture of the pipeline. The next step will be involving a node-based editor for the creation of the rendering phase...I found it very easy and powerful, something that can istantaneously change the appearence of the game to see different pipelines and render, to study the feel of the game and tune it up!
With that in mind I begun my lightmapper. Through I started only some days ago, now it output a simple lightmap with a really simple phong shading: actually I'm spending time in creating a good unwrap and to create the radiosity normal mapping brick that I need to complete this step!

Until september I've no connection at home...so updates will be randomic! :(

But...stay tuned!