I added a 2D Camera to the game. This allows zooming, panning, and rotation of everything in the game word. I’m not actually using it for anything yet, but I imagine it will be nice to have when I have to start worrying about supporting widescreen vs standard def resolutions. Also it can be used for special effects like camera shake on big explosions.
Now I noticed my Pickers movement was not as smooth as it should be, even though my frame rate was a easy solid 60 fps. Others have noticed this as well and there has been a good bit of discussion on the subject. The summary is, by default, the XNA framework runs in a fixed timing mode, fixed at 16.6 ms per update, or 60 fps. But if you do some testing of this, people have found that the end results are actually more around 58 fps, somewhere frames ARE being dropped. Depending on the kind of game and the kind of movements being done, ( or you ability to perceive such things ) it isn’t always noticeable. It was definitely bothering me, so I changed the timing mode to variable time step, and things smoothed right out.
this.IsFixedTimeStep = false;
There really is no downside to not using fixed timing, except it require you to do you own time management in the update loop. It’s simple to do, and I was already doing it anyway, a habit from previous physics related projects. Anything time related just needs to be applied against the Time Delta. So instead of moving an object by X amount because you assumed a fixed step, you move it scaled by the actual time passed:
// calculate dt, the change in time since the last frame. float dt = (float)gameTime.ElapsedGameTime.TotalSeconds; gameObject.position += gameObject.velocity * dt;
Now with things running silky smooth, I noticed another timing issue. The enemies where changing speed as they followed their path to the destination. Typically slowing down as they approached the next waypoint. It turns out that I’m not crazy, but this is normal behavior using the CatmullRom interpolation in general. Basically, if you are moving between points A and B, and you are taking steps of 1% at a time, you would expect to be 75% of the way to point B after 75 steps. This is just not the case though, you may closer or further depending on how the algorythm defines the spline. The solution to this is to find what point on the spline represents the actualy distance we want. Easier said then done. It’s really not THAT hard, this page describes the idea of measuring the arc lengths of each splice segment, and using them in a lookup table. The only problem is the implementation is left to the reader ( no cut/paste! ). So I tackled it, it took quite a bit of time and debugging, but I am happy with the results. The Enemies now move at a constant velocity in world units, no matter the structure, complexity, or irregular placement of the path waypoints they are following.