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!
Friday, December 18, 2009
Friday, December 11, 2009
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:
Stay tuned ;)
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)
Stay tuned ;)
Tuesday, December 8, 2009
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!
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!
Tuesday, November 24, 2009
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!
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!
Friday, November 13, 2009
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!
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!
Tuesday, September 22, 2009
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!!!)
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!!!)
Monday, September 21, 2009
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!
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!
Subscribe to:
Posts (Atom)