Well, a lot has happened since my last update. I added a set of cities into the game and was rendering them individually until I realized that in order to have them have different textures on them, I would need to set an Effect parameter, and constantly doing fx.Begin() and fx.End() was of course a ridiculous performance hit.
So most of yesterday was spent building a QuadRenderer class to manage the individually textured cities. The QuadRenderer maintains a dictionary of vertexbuffers and indexbuffers by texture, which has to be recompiled if the list of cities / sites changes - I plan to use this also for managing bases, crash sites and really any world elements that don't actually move.
One thing that I learned yesterday was that storing the GraphicsManager.GraphicsDevice in a shortcut variable is a really bad idea - it caused a lot of "NullReferenceException" problems until I removed the reference and just went the long way around.
The other challenge was figuring out where to put the QuadRenderer in my architecture, since ideally there would be a complete split between model and view, but as individual cities are added and removed from the model, they need to to work directly with the QuadRenderer. Since my GameManager is a singleton, I have added a QuadRenderer there, but I am not entirely happy with this solution and can see the GameManager class getting filled up with all sorts of optimization rubbish like this.
Here's a picture of the QuadRenderer in action:
Wednesday, 17 February 2010
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment