I resumed working on Nonogramm a couple of days ago and it's been going really well. First task was to migrate to XNA4 as you cannot ship XNA3 projects on XBLIG anymore.
Next, I resumed implementing the different UI pages needed for the game - most of the project is UI work anyway. The following video shows the current status where you can access a list of puzzles (randomly generated so far) and play a puzzle.
By the way, I started posting updates on Twitter as well, just search for #Nonogramm !
This is all for now!
Tuesday, 15 March 2011
Sunday, 27 February 2011
A way to avoid virtual function calls in C++
A couple of days ago, a colleague sent this link to a paper called "Executable Bloat - How it happens and how we can fight it" which was an interesting read. The point about the cost of virtual function calls and the fact that you should try to avoid them reminded me of a bit of C++ code I wrote a few years ago that tried to achieve exactly that.
The idea is to transform virtual updates into non virtual updates using templates. You go from 1 virtual update per object to either no virtual call at all or 1 virtual call per class, depending on how much performance you want to trade for flexibility.
In lots of game engines, calling virtual functions once per frame on objects is a common pattern. Such objects are generally handled in a manager that will process the each frame. I have seen this pattern in lots of codebases, no matter what style of objects hierarchies was used (either OOP-like with deep and complex class trees or more Data-Oriented entity/components systems).
A typical, although a bit naive, example of such a pattern could a renderer that would draw 3D objects. In it, you would find a base interface for everything that can be rendered (IRenderable), some concrete classes that implement this interface (Mesh and ParticleSystem) and a manager, the renderer itself, that would store the objects that needs to be drawn. Here is some pseudo-code:
With such a design, you get 1 virtual call per object. Depending on the the platform, the content of the list and some other factors, these virtual calls can become quite a significant performance hit because of cache misses.
In order to get rid of the virtual calls, we will declare 1 render manager per type of Renderable, using templates. This transforms the dispatching of the call to Render() from virtual to static. WIN!
Here's the new code:
The change from virtual to static dispatch comes with a small price though. You now have to call RenderAll() on all the different managers, which can get tedious and bug prone. To improve that, we can reintroduce polymorphism, but this time we'll do it at the manager's level. So in effect we transformed 1 virtual call per instance into 1 virtual call per class, which is likely to be a few orders of magnitude smaller.
In a real world codebase, a set of macros would surely be used for declaring and registering a new manager for each type, making the system easier to maintain and extend.
I think the approach described here works quite well for entity/components systems wit Data-Oriented Design (DOD) in mind. In such systems, your managers would also deal with allocating/deallocating the components in a memory friendly manner.
I hope that you will find all this useful in your projects!
See you next time, or maybe at GDC next week!
-m
The idea is to transform virtual updates into non virtual updates using templates. You go from 1 virtual update per object to either no virtual call at all or 1 virtual call per class, depending on how much performance you want to trade for flexibility.
In lots of game engines, calling virtual functions once per frame on objects is a common pattern. Such objects are generally handled in a manager that will process the each frame. I have seen this pattern in lots of codebases, no matter what style of objects hierarchies was used (either OOP-like with deep and complex class trees or more Data-Oriented entity/components systems).
A typical, although a bit naive, example of such a pattern could a renderer that would draw 3D objects. In it, you would find a base interface for everything that can be rendered (IRenderable), some concrete classes that implement this interface (Mesh and ParticleSystem) and a manager, the renderer itself, that would store the objects that needs to be drawn. Here is some pseudo-code:
//////////////////////////////////
// Rendering system
//////////////////////////////////
class IRenderable
{
public:
virtual void Render() = 0;
};
class Mesh : public IRenderable
{
public:
virtual void Render()
{ /* Do rendery things */ }
};
class ParticleSystem : public IRenderable
{
public:
virtual void Render()
{ /* Do rendery things */ }
};
class RenderManager
{
private:
std::vector< IRenderable * > m_Objects;
public:
void RenderAll()
{
std::vector< IRenderable * > iter = m_Objects.begin();
std::vector< IRenderable * > iend = m_Objects.end();
for( ; iter != iend; ++iter )
{
*iter->Render(); // 1 virtual call per object
}
}
};
//////////////////////////////////
// Main
//////////////////////////////////
RenderManager gRenderManager;
void main()
{
while(1)
{
gRenderManager.RenderAll();
}
}
With such a design, you get 1 virtual call per object. Depending on the the platform, the content of the list and some other factors, these virtual calls can become quite a significant performance hit because of cache misses.
In order to get rid of the virtual calls, we will declare 1 render manager per type of Renderable, using templates. This transforms the dispatching of the call to Render() from virtual to static. WIN!
Here's the new code:
//////////////////////////////////
// Rendering system
//////////////////////////////////
class Mesh // No base interface anymore
{
void Render() // Not virtual anymore
{ /* Do rendery things */ }
};
class ParticleSystem // No base interface anymore
{
void Render() // Not virtual anymore
{ /* Do rendery things */ }
};
template< class _T >
class RenderManager
{
private:
std::vector< _T * > m_Objects;
public:
void RenderAll()
{
std::vector< _T * > iter = m_Objects.begin();
std::vector< _T * > iend = m_Objects.end();
for( ; iter != iend; ++iter )
{
*iter->Render(); // this call is NOT virtual
}
}
};
//////////////////////////////////
// Main
//////////////////////////////////
RenderManager< Mesh > gRenderManager_Mesh;
RenderManager< ParticleSystem > gRenderManager_ParticleSystem;
void main()
{
while(1)
{
gRenderManager_Mesh.RenderAll();
gRenderManager_ParticleSystem.RenderAll();
}
}
The change from virtual to static dispatch comes with a small price though. You now have to call RenderAll() on all the different managers, which can get tedious and bug prone. To improve that, we can reintroduce polymorphism, but this time we'll do it at the manager's level. So in effect we transformed 1 virtual call per instance into 1 virtual call per class, which is likely to be a few orders of magnitude smaller.
/////////////////////////////////
// Rendering system
//////////////////////////////////
class Mesh
{
void Render()
{ /* Do rendery things */ }
};
class ParticleSystem
{
void Render()
{ /* Do rendery things */ }
};
class IRenderManager // Base class for all managers
{
public:
virtual void RenderAll() = 0;
};
template< class _T >
class RenderManager : public IRenderManager // all template mamangers inherit from the interface
{
private:
std::vector< _T * > m_Objects;
public:
void RenderAll()
{
std::vector< _T * > iter = m_Objects.begin();
std::vector< _T * > iend = m_Objects.end();
for( ; iter != iend; ++iter )
{
*iter->Render(); // this call is NOT virtual
}
}
};
//////////////////////////////////
// Main
//////////////////////////////////
RenderManager< Mesh > gRenderManager_Mesh;
RenderManager< ParticleSystem > gRenderManager_ParticleSystem;
std::vector< IRenderManager * > gRenderManagers; // will store all the managers
void main()
{
// at init time, add the managers into an array so we can iterate over them
// ordering is explicit, which is a nice thing (think opaque/transparent objects for instance)
gRenderManagers.push_back(&gRenderManager_Mesh);
gRenderManagers.push_back(&gRenderManager_ParticleSystem);
while(1)
{
std::vector< IRenderManager * > iter = gRenderManagers.begin();
std::vector< IRenderManager * > iend = gRenderManagers.end();
for( ; iter != iend; ++iter )
{
*iter->RenderAll();
}
}
}
In a real world codebase, a set of macros would surely be used for declaring and registering a new manager for each type, making the system easier to maintain and extend.
I think the approach described here works quite well for entity/components systems wit Data-Oriented Design (DOD) in mind. In such systems, your managers would also deal with allocating/deallocating the components in a memory friendly manner.
I hope that you will find all this useful in your projects!
See you next time, or maybe at GDC next week!
-m
#AltDevBlogADay
I just wanted to point out to whoever reads this blog that he should probably be checking http://altdevblogaday.org/. Lots of quality content there!!
Saturday, 15 January 2011
2011 !
Not much going on these days programming-wise as I'm spendig lots of time playing Gypsy Jazz guitar with some of my friends.
Just thought that I'd pass my wishes though :)
-m
Just thought that I'd pass my wishes though :)
-m
Tuesday, 23 November 2010
Progress on the Main Game UI
A really brief update on the UI that will be used in the gameplay screen. Nothing very special to report, I am working my way through XNA and I must admit that while some stuff is extra cool, some bits are getting a bit annoying like trying to use the SpriteBatch class with custom effect. This is more complex than it should be and although you can find some way around the issues and it is rather documented on te web, you just get the feeling that it could be easier than that. It is woth mentionning that I am still using XNA 3.1 and maybe these issues are fixed in 4.0. I'll upgrate to the latest version a some point in time but so far I am glad to be able tu keep using VS 2008 as I am really used to it (XNA 4.0 doesn't install on pre VS2010 to my knowledge).
Also, I am getting a bit worried by the performances, mainly because of the gaussian blur shader that I use in a few places. I could repalce that by a Poisson disk blur filter which I may do after the game is implemented. The way I use the SpriteBatch also seems really inefficient so hopefully there will be plenty of room for optimization without struggling that much.
Here is a video of how it looks so far:
-m
Also, I am getting a bit worried by the performances, mainly because of the gaussian blur shader that I use in a few places. I could repalce that by a Poisson disk blur filter which I may do after the game is implemented. The way I use the SpriteBatch also seems really inefficient so hopefully there will be plenty of room for optimization without struggling that much.
Here is a video of how it looks so far:
-m
Friday, 19 November 2010
More work on the UI
Some visual improvements, plus another, more complex UI page.
This is all coming along very well and I am uite pleased and excited :)
-m
This is all coming along very well and I am uite pleased and excited :)
-m
Monday, 15 November 2010
First version of the Game UI
I have been working on the UI system for my XNA game since most of the added value will be a neat presentation layer. I came up with a fairly simple UI system that builds up on my state machine class I talked about last time. The whole thing is rather straightworward to use. Here is a quick video of it in action:
One of the interesting thing about this UI framework is the ability for any widget to specify its neighours, so when the focus moves, the UI page can figure out who should recieve the focus. Here is a snippet from the UIWidget class which is base for all widgets:
public class UIWidget : StateMachine
{
...
public UIWidget LeftNeighbour
{
get;
set;
}
public UIWidget RightNeighbour
{
get;
set;
}
public UIWidget UpNeighbour
{
get;
set;
}
public UIWidget DownNeighbour
{
get;
set;
}
...
}
Widgets are laid out on UIPage objects. A UIPage keeps track of the focussed widget and processes pad inputs. When recieving a pad message, it picks the right neibour from the focussed widget and transfers focus to it. Note that multiple controls can have the same neighbour for a particular direction, so you can create rather complex layouts with a bit of work.
That's all for today!
One of the interesting thing about this UI framework is the ability for any widget to specify its neighours, so when the focus moves, the UI page can figure out who should recieve the focus. Here is a snippet from the UIWidget class which is base for all widgets:
public class UIWidget : StateMachine
{
...
public UIWidget LeftNeighbour
{
get;
set;
}
public UIWidget RightNeighbour
{
get;
set;
}
public UIWidget UpNeighbour
{
get;
set;
}
public UIWidget DownNeighbour
{
get;
set;
}
...
}
Widgets are laid out on UIPage objects. A UIPage keeps track of the focussed widget and processes pad inputs. When recieving a pad message, it picks the right neibour from the focussed widget and transfers focus to it. Note that multiple controls can have the same neighbour for a particular direction, so you can create rather complex layouts with a bit of work.
That's all for today!
Friday, 12 November 2010
C# State Machine class
For my little XNA game that I am developping at the moment, the main thing I needed was a simple Finite State Machine class that I could use as the basis for prtty much any game object, especially for all the GUI and GameState logic.
I didn't want to spend too much time on a framework or grab one of the many libraries available here and there and then spend some time learning how to use it. Instead, I had the feeling that using the reflection capabilities of C#, I could easily and quickly come up with a simple piece of code that would fulfill my needs for this project. Functionnality-wise, my inspiration was Steve Rabin's article about a set of C++ macros for writing simple state machines. I used them quite a lot in the past and liked the fact the simple feature set, perfectly suited for small scale projects.
Basically, a State Machine can be in a certain number of differnt states and transition from one to another. Each state has:
StateName__Handler(...)
As a quick example to make that obvius, let's have a look at the Default state (which does nothing at all):
public virtual void Default__Enter(string _OldState){}
public virtual void Default__Exit(string _NewState){}
public virtual void Default__Update(GameTime _GameTime){}
On top of that, each state can define message handlers for any message it wants to support. Message are defined by a simple string. For instance, the handler for a message called TakeDamage in the Default state and parametrized with an amount of damage points would imply the following bits:
public virtual void Default__TakeDamage(int _Damage)
{
Health -= _Damage;
}
And game code would send the message like this:
Target.ProcessMessage( "TakeDamage", 10 );
As you can see this is all really simple. But here comes the goodness :)
{
Health -= _Damage;
}
public virtual void Invincible__TakeDamage(int _Damage)
{
}
{
public virtual void Default__TakeDamage(int _Damage)
{
Health -= _Damage;
}
}
class SoldierFragile : Soldier
{
public virtual void Default__TakeDamage(int _Damage)
{
Health -= _Damage * 5;
}
}
The implementation might be rather simple and compact but it'still quite powerfull as you can see.
However, nothing is perfect in this world and I am sure some design choices are arguable ... but they suit my needs so I'm fine with it. I think the major concerns would be:
Feedback welcome !
-m
I didn't want to spend too much time on a framework or grab one of the many libraries available here and there and then spend some time learning how to use it. Instead, I had the feeling that using the reflection capabilities of C#, I could easily and quickly come up with a simple piece of code that would fulfill my needs for this project. Functionnality-wise, my inspiration was Steve Rabin's article about a set of C++ macros for writing simple state machines. I used them quite a lot in the past and liked the fact the simple feature set, perfectly suited for small scale projects.
Basically, a State Machine can be in a certain number of differnt states and transition from one to another. Each state has:
- an Enter() function callled when this state becomes active. This is the perfect place to do per-state setups
- an Update() function that should be called once per frame
- an Exit() function, called when leaving a state for another one. This is the perfect place to do some cleanup before leaving the state
StateName__Handler(...)
As a quick example to make that obvius, let's have a look at the Default state (which does nothing at all):
public virtual void Default__Enter(string _OldState){}
public virtual void Default__Exit(string _NewState){}
public virtual void Default__Update(GameTime _GameTime){}
On top of that, each state can define message handlers for any message it wants to support. Message are defined by a simple string. For instance, the handler for a message called TakeDamage in the Default state and parametrized with an amount of damage points would imply the following bits:
public virtual void Default__TakeDamage(int _Damage)
{
Health -= _Damage;
}
And game code would send the message like this:
Target.ProcessMessage( "TakeDamage", 10 );
As you can see this is all really simple. But here comes the goodness :)
- You can have handlers that handle the same message differently per state:
{
Health -= _Damage;
}
public virtual void Invincible__TakeDamage(int _Damage)
{
}
- You can derive a state machine class from an existing class and override handlers so they do different things:
{
public virtual void Default__TakeDamage(int _Damage)
{
Health -= _Damage;
}
}
class SoldierFragile : Soldier
{
public virtual void Default__TakeDamage(int _Damage)
{
Health -= _Damage * 5;
}
}
The implementation might be rather simple and compact but it'still quite powerfull as you can see.
However, nothing is perfect in this world and I am sure some design choices are arguable ... but they suit my needs so I'm fine with it. I think the major concerns would be:
- Weak state referencing as it is all done by strings and naming convention. So if you write typos or rename stuff around, this is likely to break. More error handling could be added but ultimately, this is just a string and this is rather fragile.
- State specific variables will live at instance scope, not state scope. This is because I want to be able to acces the state machine members from anystate (this reduces the nb of accessors and stuff you need to write)
Feedback welcome !
-m
Wednesday, 10 November 2010
Another project !
I've been thinking quite a lot about what's motivationg me in writing code and games at home, as this is also what I do for a living (lucky me!). More specifically I tried to analyze why I statrt lots of projects and rarely finish any of them. Long story short, I think it all boils down to me being more interested in writing nice code and developping a nice tech that creating a fully finished game with it as the ratio of time spent on thinking about tech vs game is probably 20:1 ... All that is great and I've learnet and keep learning a lot from this "R&D" but this doesn't provide the rewarding feeling of having completed something entirely (which is a really really nice one - I've expereienced it twice recently when finishing the development of Enslaved - Odyssey to the West and its DLC)
So to break that cycle, I want to start working on a project that has the opposite characteristics of my usual projects:
In the meantime, take care !
-m
So to break that cycle, I want to start working on a project that has the opposite characteristics of my usual projects:
- Not technically challenging, so there is no opportunity to get sidetracked/lured by interesting problems to solve
- Design is simple, achievable end well established, so again there is not a lot of fiddling around with tons of ideas before getting a grasp of what thet game I want to make is all about
- Added value is in the final product being neat and polished
- Not attached to its codebase. This is a weird one but over the years, I realized that if I write a C++ engine for a game, I get really attached to the codebase and want to make it as neat and well architectured as can be - certainly because I have this long term project of coming up with some tech that is full-featured enough for XBLA-scope projects. On the other hand, I tend to consider code written in any other language as some discardable one-off thing where I wont bother spend ages polishing code to death. Consequently, I'll write this new project in C# / XNA so I can get it done quickly, because the language is inherently efficient and because I won't be too bothered to hack things around when needed. (Moreover, I think there are a lot of lessons to learn from the XNA architecture that I could apply in my C++ engine)
- A 1 person project. I don't want to depend on anyone nor have people depending on me for this project. No that peaolpe I have been working with on other stuff are a problem - I love them and they are skilled/reliable/etc ... but I just want to try something different this time. This mean almost no art/anim etc as I can do basic stuff but that's it :) I am also looking forward to the music/sound bit as this will bridge my passion for code/games and playing music :)
In the meantime, take care !
-m
Thursday, 2 September 2010
Material Editor Prototype
It's been a couple of weeks since my last post, mostly because I've been quite busy at work, but also because I reached a point in my work on the Light PrePass renderer where I need to sleep on it for a bit so I can then clean the code and improve what I have (this is how I do most of my refactor ... write stuff, stop and think aboutit, refactor/remove code/make it nice ... then rince, repeat).
In the meantime, I started working on the future Material Editor that I will need when the renderer is up ad running. I want a node-based editor a la UnrealEd or other graphical shader editors. And having this king of graph editor would be handy for other stuff like animation trees, visual level scripting tool (a la Unreal Kismet), state machines, etc ...
My toolchain is written mostly in C# (I'll develop the link Engine/Editor in a future post) so writing GUI is not as bad as the usual C++/MFC nightmare. Moreover, I found a superb 2D drawing library called Piccolo.NET a few years ago and its concept of Zoomable User Interface (ZUI) is exactly what I needed for this project. After a few days of work, I have a first version of the GUI running with some underlying graph model behind it. It supports Undo/Redo via a bunch of undoable commands that modify the graph Model. Modifications of the Model generate events that the UI hooks onto and mirror.
I'll give more details about the internals when the code design gets a bit more stable as it is still in early stages, but I am really pleased with the result so far.
Time to conclude with a screenshot :)
In the meantime, I started working on the future Material Editor that I will need when the renderer is up ad running. I want a node-based editor a la UnrealEd or other graphical shader editors. And having this king of graph editor would be handy for other stuff like animation trees, visual level scripting tool (a la Unreal Kismet), state machines, etc ...
My toolchain is written mostly in C# (I'll develop the link Engine/Editor in a future post) so writing GUI is not as bad as the usual C++/MFC nightmare. Moreover, I found a superb 2D drawing library called Piccolo.NET a few years ago and its concept of Zoomable User Interface (ZUI) is exactly what I needed for this project. After a few days of work, I have a first version of the GUI running with some underlying graph model behind it. It supports Undo/Redo via a bunch of undoable commands that modify the graph Model. Modifications of the Model generate events that the UI hooks onto and mirror.
I'll give more details about the internals when the code design gets a bit more stable as it is still in early stages, but I am really pleased with the result so far.
Time to conclude with a screenshot :)
Subscribe to:
Posts (Atom)