I haven’t programmed games for about 10 years (My last experience was DJGPP + Allegro), but I thought I’d check out XNA over the weekend to see how it was shaping up.
I am fairly impressed, however as I continue to piece together a game engine, I have a (probably) basic question.
How much should you rely on C#’s Delegates and Events to drive the game? As an application programmer, I use delegates and events heavily, but I don’t know if there is a significant overhead to doing so.
In my game engine, I have designed a ‘chase cam’ of sorts, that can be attached to an object and then recalculates its position relative to the object. When the object moves, there are two ways to update the chase cam.
- Have an ‘UpdateCameras()’ method in the main game loop.
- Use an event handler, and have the chase cam subscribe to object.OnMoved.
I’m using the latter, because it allows me to chain events together and nicely automate large parts of the engine. Suddenly, what would be huge and complex get dropped down to a handful of 3-5 line event handlers…Its a beauty.
However, if event handlers firing every nanosecond turn out to be a major slowdown, I’ll remove it and go with the loop approach.
Ideas?
If you were to think of an event as a subscriber list, in your code all you are doing is registering a subscriber. The number of instructions needed to achieve that is likely to be minimal at the CLR level.
If you want your code to be generic or dynamic, then you’re need to check if something is subscribed prior to calling an event. The event/delegate mechanism of C# and .NET provides this to you at very little cost (in terms of CPU).
If you’re really concerned about every clock cycle, you’d never write generic/dynamic game logic. It’s a trade off between maintainable/configurable code and outright speed.
Written well, I’d favour events/delegates until I could prove it is an issue.
The only way you’ll truly know if it is an issue for you is by profiling your code — which you should do anyway for any game development!