Okay, I know I said that I was going to make something a bit more building like next and, well, here you go:
Look! It’s got a plinth and everything! Well, okay, it’s not very exciting, and I’ll be honest, there’s very little extra making-it-look-like-a-building code in there – I’ve simply added another box and changed their sizes slightly. But there’s a bit more gone on behind the scenes:
First, in the first pass, each face had the texture coordinates clamped to (0,0) -> (1,1) across the face, which meant that the textures looked oddly squished or stretched on anything other than a perfectly square face. Now, the texture coordinates are calculated according to face size; a 1×1 world-unit square will have the entire texture exactly mapped to it – we’ll worry about changing this scale to more useful units later.
Secondly, in the first pass, I wasn’t doing things in a very XNA-like style: from my Building class, I was reaching inside the Game to grab the camera matrices to set up for rendering. Whilst this is entirely possible, it’s a bit ugly and leads to lots of unpleasant tangled dependencies. XNA provides a concept of “Game Services” – essentially public interfaces to objects that can be queried for from the main Game object. So, instead of reaching inside the Game for the camera matrices, we now have a Camera GameObject, and an ICamera service for it. The Camera is registered as a GameObject and a service, and then later on, the Building can query the Game for an ICamera object, and get the view and projection matrices from that instead. We also use the IGraphicsDeviceService that is provided by default, rather than grabbing that from inside Game, too.
Thirdly, the application can now be quit simply by hitting Escape, as I’ve added some simple keyboard state monitoring.
And lastly, I’ve changed the game from the default fixed update rate to variable update rate; I’m not entirely sure why XNA defaults to a fixed update rate – most games I know of use variable timesteps – and in XNA, it actually causes problems. The Update() (and Draw()) methods of GameComponents can lag behind in certain circumstances – for example, if the window is moved, or if input focus is switched – leading to unpleasant stalls in your game. Simply switching off fixed timesteps fixes this – and hey, it’s not 1993 any more, we can cope with writing our physics/AI solvers to deal with variable framerates.
As before, the code is at http://bzr.parm.net/Cityscape/ – this post refers to trunk revision 8.
Tags: c#, Cityscape, photorealism, programming, XNA