I know I know...I ended up with only 1 day of programming.
But some days after, I ended doing an interview @ Codemasters.
And the big news is...NOW I WORK AT CODEMASTERS!!!
A big leap into the possibility to grew and study techniques, doing a work that I LOVE with a great company!
But hey...and your challenge?
My challenge is returnig back, even if I decided to restart again from scratch.
Why that?
In the meantime I've read some books around (mainly c++ stuff...) and ended up with some new ideas.
Also, my will is to create a framework to explore all these papers and thesis around the web that take my attention!
But all of this will not happen now, first I have to enter in the apartment and get all the stuff out of the boxes!
Stay tuned for more infos!
Saturday, May 8, 2010
Friday, March 19, 2010
Progress report: Day 1
Yesterday it was my first game-engine development day.
As you know, I'm facing the challange of creating a small game-engine in 10 days.
This can be considered a game to improve speed and understanding of a game engine and the decisions about the design. I found that personally, when coding at home (without time constraint) I need to study too much time before taking a decision on design. After this decision is taken, and some UML written down, I code with all in my mind (and papers) in a good way.
To improve the decision time I choose the way of training myself (as with guitar, breakdancing, motorbikes...).
What is the first principle of training? Practice, practice and PRACTICE.
Reading some books of NLP and Self-Improvement, I found in Anthony Robbins a perfect description of what he call the 'decision muscle':
Decision -> Action -> Results and Feedback.
It is the SAME as a controller in a dynamic system (automation systems...), and applies to all the field of the life.
And decision making is crucial also in engine design.
To improve decision making, I found really useful four things:
So finally I decided to begun another iteration of my home-engine with new knowledge from books and papers.
FIRST DAY
I've almost finished the Platform Abstraction Layer, on which every other layer will rely.
The first thing I noticed is that you must create a complete environment for other programmers to work with your engine. Many times, due to lack of documentation or time to study, it's better to create restrictions to code use and rails for the other programmers.
For example, if you want the complete control of how classes are accessed, you can create some macros that fordib (declare private) copy constructor and equal operator. Or you can typedef pointer, const pointer, reference and such and use ALWAYS them.
Another example can be the error detection: a bunch of macros like _CHECK( condition ), or _ASSERT( condition ), _ASSERTNOFAIL (condition ) can be EXTREMELY useful to have a consistent way of developing. With that you can redirect all these macros to write down in a global output device you messagges, and this can be in a transparent way to programmers: think of an external window that brings up when you are in debug, with all informations sent everytime a check fail (or success), something missing, asserting.
Consistency is the key.
Decide the guideline in how you want to handle situations, and then use all the c++ features to create this Consistency.
Watching other code I've felt that when you give too much degree of freedom in the code to other using your engine, they will always do what you have not expected.
This leads to the need of "extending" C++, or use it to place constraint and quickly change behaviour.
Constraints.
Flexibility.
These two words commonly are the opposite, but have a variable number of choises, but with precise choises, leads to choose one of the path you thinked of.
Take the following code snippet:
HBOOL WorkerThread::GiveUpSomeWork(WorkerThread* pIdleThread)
{
SpinMutexLock Locker;
_HPKM_CHECK(Locker.TryLock(&m_oTaskMutex));
_HPKM_CHECK(!m_uiTaskCount);
// Grab work
SpinMutexLock LockIdleThread(&pIdleThread->m_oTaskMutex);
// Taskpool has some new tasks, quit.
_HPKM_CHECK(pIdleThread->m_uiTaskCount);
// We have only 1 task, try to split it.
if (m_uiTaskCount == 1)
{
TaskPtr pTask = HNULL;
if (m_apTasks[0]->Split(pIdleThread, &pTask))
{
pTask->m_pCompletion->MarkBusy(HTRUE);
pIdleThread->m_apTasks[0] = pTask;
pIdleThread->m_uiTaskCount = 1;
return HTRUE;
}
}
// Grab half tasks (rounding up)
U32 uiGrabCount = (m_uiTaskCount + 1) / 2;
// Copy this thread tasks to the idle thread list.
TaskPtrPtr ppTask = pIdleThread->m_apTasks;
U32 i;
for (i = 0; i < uiGrabCount; i++)
{
*ppTask++ = m_apTasks[i];
m_apTasks[i] = HNULL;
}
pIdleThread->m_uiTaskCount = uiGrabCount;
// Move remaining tasks down
ppTask = m_apTasks;
for ( ; i < m_uiTaskCount; i++)
{
*ppTask++ = m_apTasks[i];
}
m_uiTaskCount -= uiGrabCount;
return HTRUE;
}
The macro _HPKM_CHECK checks the condition and return HFALSE if the condition is not met.
This in the Release version. In debug or profile version, you can substitute it with other commands that send an event to an output device, or maybe print something in the game console.
As you saw, also TaskPtr type is a typedef. This ensure that we can test and let some classes use smart pointers, provide timings about access with/without smart pointers in a transparent way.
As Engine Programmer, engine is not only a c++ (and a bunch of other languages in other subsystems...) code mess, but a TOOL with which everyone MUST express himself.
For me, this is something that really lacks in many engines, even commercial ones.
Placing many smalls constraint, guides and hints gives everyone the power to use the engine as its full glory.
With macros, templates, defines (really not new stuff...) you have to give CREDITED TOOLS to code with.
You have to redirect almost ALL calls inside your code in a way YOU decide.
Almost EVERY method call must be under your control. Even simple memcpy, strlen, sin...they must be wrapped and even in the case of using the standard functions, you have to decide it.
This TOTAL ABSTRACTION (almost) leads to better code control and later optimization.
Even in coding, DECIDING ALL is the key! Decide that every sin call leads to a modified version, maybe with a table-lookup, or to the standard function. But you have to DECIDE!
Outside of those condiserations, I've worked on the platform abstraction. This includes:
The almost-hated virtual table, a good enemy on xbox360 and ps3 intensive operations, can be achieved in very straightforwarding way.
The final result is an almost controlled window that takes its messagges and call its task pool to use every kind of task possible divided on all the worker threads.
I'm implementing some interesting things like parallel data processing (parallel_for...) and want to contiune this way.
Of course, these are all mine thoughs and I know that there are many other way of doing the same thing better.
But you know, I have 9 more days to end the engine!
Demiurge
As you know, I'm facing the challange of creating a small game-engine in 10 days.
This can be considered a game to improve speed and understanding of a game engine and the decisions about the design. I found that personally, when coding at home (without time constraint) I need to study too much time before taking a decision on design. After this decision is taken, and some UML written down, I code with all in my mind (and papers) in a good way.
To improve the decision time I choose the way of training myself (as with guitar, breakdancing, motorbikes...).
What is the first principle of training? Practice, practice and PRACTICE.
Reading some books of NLP and Self-Improvement, I found in Anthony Robbins a perfect description of what he call the 'decision muscle':
Decision -> Action -> Results and Feedback.
It is the SAME as a controller in a dynamic system (automation systems...), and applies to all the field of the life.
And decision making is crucial also in engine design.
To improve decision making, I found really useful four things:
- Learn more. Learn all. Many times knowing different techniques improves you understanding of other problems: any techniques, and desing has a mentality behind.
Learning the MENTALITY is powerful. Then apply to other fields. Eg: data oriented structure of arrays used in vectorized math and shaders, can be successufully applied to game objects (Pitfalls_of_Object_Oriented_Programming paper is a good example). - Try completely different approaches.
- Practice, practice, practice!
- Learn from mistakes:
there are no failure, there are only results
(Robbins)
So finally I decided to begun another iteration of my home-engine with new knowledge from books and papers.
FIRST DAY
- Total time: 10 hours
- Evident results: running up window, multithread engine loop on.
I've almost finished the Platform Abstraction Layer, on which every other layer will rely.
The first thing I noticed is that you must create a complete environment for other programmers to work with your engine. Many times, due to lack of documentation or time to study, it's better to create restrictions to code use and rails for the other programmers.
For example, if you want the complete control of how classes are accessed, you can create some macros that fordib (declare private) copy constructor and equal operator. Or you can typedef pointer, const pointer, reference and such and use ALWAYS them.
Another example can be the error detection: a bunch of macros like _CHECK( condition ), or _ASSERT( condition ), _ASSERTNOFAIL (condition ) can be EXTREMELY useful to have a consistent way of developing. With that you can redirect all these macros to write down in a global output device you messagges, and this can be in a transparent way to programmers: think of an external window that brings up when you are in debug, with all informations sent everytime a check fail (or success), something missing, asserting.
Consistency is the key.
Decide the guideline in how you want to handle situations, and then use all the c++ features to create this Consistency.
Watching other code I've felt that when you give too much degree of freedom in the code to other using your engine, they will always do what you have not expected.
This leads to the need of "extending" C++, or use it to place constraint and quickly change behaviour.
Constraints.
Flexibility.
These two words commonly are the opposite, but have a variable number of choises, but with precise choises, leads to choose one of the path you thinked of.
Take the following code snippet:
HBOOL WorkerThread::GiveUpSomeWork(WorkerThread* pIdleThread)
{
SpinMutexLock Locker;
_HPKM_CHECK(Locker.TryLock(&m_oTaskMutex));
_HPKM_CHECK(!m_uiTaskCount);
// Grab work
SpinMutexLock LockIdleThread(&pIdleThread->m_oTaskMutex);
// Taskpool has some new tasks, quit.
_HPKM_CHECK(pIdleThread->m_uiTaskCount);
// We have only 1 task, try to split it.
if (m_uiTaskCount == 1)
{
TaskPtr pTask = HNULL;
if (m_apTasks[0]->Split(pIdleThread, &pTask))
{
pTask->m_pCompletion->MarkBusy(HTRUE);
pIdleThread->m_apTasks[0] = pTask;
pIdleThread->m_uiTaskCount = 1;
return HTRUE;
}
}
// Grab half tasks (rounding up)
U32 uiGrabCount = (m_uiTaskCount + 1) / 2;
// Copy this thread tasks to the idle thread list.
TaskPtrPtr ppTask = pIdleThread->m_apTasks;
U32 i;
for (i = 0; i < uiGrabCount; i++)
{
*ppTask++ = m_apTasks[i];
m_apTasks[i] = HNULL;
}
pIdleThread->m_uiTaskCount = uiGrabCount;
// Move remaining tasks down
ppTask = m_apTasks;
for ( ; i < m_uiTaskCount; i++)
{
*ppTask++ = m_apTasks[i];
}
m_uiTaskCount -= uiGrabCount;
return HTRUE;
}
The macro _HPKM_CHECK checks the condition and return HFALSE if the condition is not met.
This in the Release version. In debug or profile version, you can substitute it with other commands that send an event to an output device, or maybe print something in the game console.
As you saw, also TaskPtr type is a typedef. This ensure that we can test and let some classes use smart pointers, provide timings about access with/without smart pointers in a transparent way.
As Engine Programmer, engine is not only a c++ (and a bunch of other languages in other subsystems...) code mess, but a TOOL with which everyone MUST express himself.
For me, this is something that really lacks in many engines, even commercial ones.
Placing many smalls constraint, guides and hints gives everyone the power to use the engine as its full glory.
With macros, templates, defines (really not new stuff...) you have to give CREDITED TOOLS to code with.
You have to redirect almost ALL calls inside your code in a way YOU decide.
Almost EVERY method call must be under your control. Even simple memcpy, strlen, sin...they must be wrapped and even in the case of using the standard functions, you have to decide it.
This TOTAL ABSTRACTION (almost) leads to better code control and later optimization.
Even in coding, DECIDING ALL is the key! Decide that every sin call leads to a modified version, maybe with a table-lookup, or to the standard function. But you have to DECIDE!
Outside of those condiserations, I've worked on the platform abstraction. This includes:
- All types redefinition;
- Multithread-pooltask implementation (completely abstract);
- Timing management;
- Engine architecture based on an abstract engine, and external-declared subsystems;
- Client definition (under Windows a window that handle OS messagges);
The almost-hated virtual table, a good enemy on xbox360 and ps3 intensive operations, can be achieved in very straightforwarding way.
The final result is an almost controlled window that takes its messagges and call its task pool to use every kind of task possible divided on all the worker threads.
I'm implementing some interesting things like parallel data processing (parallel_for...) and want to contiune this way.
Of course, these are all mine thoughs and I know that there are many other way of doing the same thing better.
But you know, I have 9 more days to end the engine!
Demiurge
Wednesday, March 17, 2010
Challenge!
I've always found that when you rise a challenge to yourself, and take it seriously, this can lead to intersting results.
I want to work on my decision-time, that I want to improve, and also speed up my coding abilities.
So I decided to rise a challenge: write a multi-threading mini-game engine in the shortest time possible. I'm deciding to give me a time of 10 days. I know for sure that there are days in which I'll not even have my pc with me (next weekend, and next week a couple of days...) but I want to try this.
The goal is to provide a basic framework for windows7, directx9.0c, cg capable of letting me create a small game.
Will I be strong enough to win?
Let's see!
Every day I'll write down on which part I'll work.
The challenge will begin thursday, so stay tuned!
I want to work on my decision-time, that I want to improve, and also speed up my coding abilities.
So I decided to rise a challenge: write a multi-threading mini-game engine in the shortest time possible. I'm deciding to give me a time of 10 days. I know for sure that there are days in which I'll not even have my pc with me (next weekend, and next week a couple of days...) but I want to try this.
The goal is to provide a basic framework for windows7, directx9.0c, cg capable of letting me create a small game.
Will I be strong enough to win?
Let's see!
Every day I'll write down on which part I'll work.
The challenge will begin thursday, so stay tuned!
Wednesday, February 17, 2010
Skinning!
Finally I've made skinning!
http://www.youtube.com/watch?v=SwAIHFE64v0
This is a small video that shows the skinning with an FBX model! I'm satisfied for that, even if it costs me too much time due to the lack of documentation as of FBX...
But now I understood (with many trials and errors) the way to retrieve animation data, skeleton, meshes and material informations.
Next step it will be a big overall change of the engine in all its parts, because I've seen the current architecture is quite messy and it is not organized in a way I like.
This iteration of the engine, as already mentioned, is intended to cover all the aspect of an engine, and not only rendering (as my previous 2 engines).
Stay tuned for more informations!
http://www.youtube.com/watch?v=SwAIHFE64v0
This is a small video that shows the skinning with an FBX model! I'm satisfied for that, even if it costs me too much time due to the lack of documentation as of FBX...
But now I understood (with many trials and errors) the way to retrieve animation data, skeleton, meshes and material informations.
Next step it will be a big overall change of the engine in all its parts, because I've seen the current architecture is quite messy and it is not organized in a way I like.
This iteration of the engine, as already mentioned, is intended to cover all the aspect of an engine, and not only rendering (as my previous 2 engines).
Stay tuned for more informations!
Friday, February 12, 2010
Rendering design thoughts
I opened a really interesting discussion @ gamedev:
http://www.gamedev.net/community/forums/topic.asp?topic_id=561645
I'm brainstorming and sharing my thoughts about rendering, and the mentality behind the renderer I use in my engine.
Take a look!
http://www.gamedev.net/community/forums/topic.asp?topic_id=561645
I'm brainstorming and sharing my thoughts about rendering, and the mentality behind the renderer I use in my engine.
Take a look!
Monday, February 8, 2010
FBX, skinning and exploration
Finally I came up coding an importer that can give me the possibility to access data that include mesh, skeleton, animations and materials.
This is a HUGE step ahead in importing asset for the engine, and this lead me to other type of battles and thoughs.
I found FBX lacking of documentation, the only serious source code is made by a guy that created an FBX importer using DirectX10 and very kindly provided the source.
Still, I wanted to use FBX as an INTERMEDIATE format, that is translated in my own internal format, for speed purpose: I'm also using Collada as intermediate format,
but still I have problems in exporting in Max2010 (a beautiful CRASH).
Next days I hope I'll publish some pics (or maybe a video) showing the skinning.
The BIG improvement coming from the skinning integration is the focusing on the problem concerning the render of different kind of geometries...this is really fascinating, because
I know for sure I'll change all my rendering code very soon. Why that? Simply because I want to *explore* other way of rendering, I've always used direct rendering but now I want to change to other solution, and found in deferred rendering (not deferred light rendering, this with light-pre-pass was done on the previous iteration of Hydra) a new way of thinking: create a command buffer, one for each thread, and then add commands from every thread.
A final merge and the rendering, and you have deferred rendering.
I read some posts around the web, and also the emergent presentation about this, and I found really a good way of thinking the rendering as a multithreading process.
The other BIG improvement is the way of thinking "data oriented"...it is really amazing, basically it is a way of thinking based on data ACROSS objects, and not only objects...so objects became a set of properties and data, but not in a constraint way.
It is really 'holistic' way of thinking about the code, and I want to try very different way of doing the same thing.
Strange is the fact that coding is the process of transform informations, nothing more, nothing less. And we are experiencing a BIG process of letting all more complicated.
Multithreading is taking to the road of seeing programming with a different level of detail, no more safety and simple flow, but a more wider use of the machine and its power.
Speaking of exploration...I'm really sad about the announcement about Castlevania:Lord of Shadows. It will be another GodOfWar clone with no more exploration...
This is a HUGE step ahead in importing asset for the engine, and this lead me to other type of battles and thoughs.
I found FBX lacking of documentation, the only serious source code is made by a guy that created an FBX importer using DirectX10 and very kindly provided the source.
Still, I wanted to use FBX as an INTERMEDIATE format, that is translated in my own internal format, for speed purpose: I'm also using Collada as intermediate format,
but still I have problems in exporting in Max2010 (a beautiful CRASH).
Next days I hope I'll publish some pics (or maybe a video) showing the skinning.
The BIG improvement coming from the skinning integration is the focusing on the problem concerning the render of different kind of geometries...this is really fascinating, because
I know for sure I'll change all my rendering code very soon. Why that? Simply because I want to *explore* other way of rendering, I've always used direct rendering but now I want to change to other solution, and found in deferred rendering (not deferred light rendering, this with light-pre-pass was done on the previous iteration of Hydra) a new way of thinking: create a command buffer, one for each thread, and then add commands from every thread.
A final merge and the rendering, and you have deferred rendering.
I read some posts around the web, and also the emergent presentation about this, and I found really a good way of thinking the rendering as a multithreading process.
The other BIG improvement is the way of thinking "data oriented"...it is really amazing, basically it is a way of thinking based on data ACROSS objects, and not only objects...so objects became a set of properties and data, but not in a constraint way.
It is really 'holistic' way of thinking about the code, and I want to try very different way of doing the same thing.
Strange is the fact that coding is the process of transform informations, nothing more, nothing less. And we are experiencing a BIG process of letting all more complicated.
Multithreading is taking to the road of seeing programming with a different level of detail, no more safety and simple flow, but a more wider use of the machine and its power.
Speaking of exploration...I'm really sad about the announcement about Castlevania:Lord of Shadows. It will be another GodOfWar clone with no more exploration...
Thursday, January 14, 2010
Happy new year!
Finally...2010! Happy new year!
I feel very excited about the new year: it begans with many news, not all good, but changes are coming!
I'm rean completion of the base rendering system of the new engine, I'm working on multithreading and I fell in love with Data-Oriented Programming mentality!
Next days I'll have FBX model ready to draw with every shader again, deferred/forward/light-pre-pass easy to switch and already implemented, then I'll move to finalize the multithreading base and physics base.
I want to experiment with a multithreaded framework, to see how can I achieve good performance and stability and usability!
Stay tuned...new experiments awaits!
I feel very excited about the new year: it begans with many news, not all good, but changes are coming!
I'm rean completion of the base rendering system of the new engine, I'm working on multithreading and I fell in love with Data-Oriented Programming mentality!
Next days I'll have FBX model ready to draw with every shader again, deferred/forward/light-pre-pass easy to switch and already implemented, then I'll move to finalize the multithreading base and physics base.
I want to experiment with a multithreaded framework, to see how can I achieve good performance and stability and usability!
Stay tuned...new experiments awaits!
Subscribe to:
Posts (Atom)