Okay, so I'm in the process of developing my own 2D, vertical scrolling shooter game, and after reading the article about fixed time stepping here on flipcode, I decided to start playing around with the fixed time steps. I have it working, however I'm having the jittery motion problem as many have described. I have started to implement interpolation between frames, and it seems to be working for the most part, but I am still getting occasional jitter and I'm not quite sure why.

I'm starting to suspect it's something else in my code, because when I switch back to variable time steps, I get small occasional jitter also, and I'm not sure if its my code, or maybe some directx failure, or me not initialising direct x correctly. So I'm going to write a small test from scratch that implements the very basic parts of my scrolling code. This will hopefully allow me to eliminate many things.

ANYWAY... all this fussing around has got me thinking, since the idea for this game has partly spawned from my love of the older game 'Raptor: Call of the shadows', I was wondering how smooth scrolling and other 2D motion was implemented back then. Was fixed time stepping the standard? Or variable time steps? Did they do any kind of interpolation? I would assume since they had very little clock cycles to play with they wouldn't have, but I'm just curious in a bit of history.

So does anyone know? Maybe someone used to work for a large games company back in the dos gaming world. Id be interested to see.

Well I wrote a game back in 1994 for Apogee and Raptor was in beta test when we where. Back then I did something very,very mad and bad. I locked the frame rate of Wacky Wheels to a certain FPS , which was a mistake. I did this because we had net play (Second game after Doom to do it) and I had to lock between different machines. Back then the only reliable way was the frame rate so I ended up going for broke.

I cannot speak for Raptor but I guess it used variable time step. I would try and get a look at the Wolfenstein or old Doom code (Which you can download) and see what they did).

But remember we did not have Windows to get in the way back then. So we owned the machine and basically nothing else was running in the background. In fact I remember writing a scroller (Like yours) and locking to the vertical retrace gave me ultra smooth movement with variable rate.

Ahh yes I remember wacky wheels. One of the first PC games I played because the machine we bought came pre loaded with many shareware titles. It was one of my favourites, along with One Must Fall and Doom.

I had thought about looking through the source code to Wolfenstein or Doom, which I actually have saved somwhere, but I remember looking through Doom's code a while back and it took me a long time to figure out what was going on in just a small section. So I thought it would be easier to just try and start a small discussion. I will no doubt have another look through them again at some point, but for now I think I might concentrate most of my energy into solving my problem.

I wish other large companies thought the same as ID and released the source to their old games. It would be quite interesting to see how they managed to do certain things and would definatly be a good learning tool, or maybe a 'what not to do' at the least. :)

What method are you using to query time periods? You will witness jittering in both fixed and variably clocked game systems if your timer is getting quantized at any point.

I your actual frame rate is reasonably steady, you can "fix" low-res timig by blurring it. I have some (well-working) code if anyone is interested...

I have made some games for the Amiga and the only way to get real silky smooth motion was to wait for the vertical retrace (e.g. sync to the monitor frequency).

Back then this was no issue since everyone had a 50hz monitor. Then after a while people started getting monitors with higher frame-rates and you had problems.

still the smoothness in 2d games when locked to the monitor is unparalelled and I think still cant be matched with variable speed.
Maybe if you use 3d hardware to display 2d sprites you might get fluid motion since you can use floating points as coordinates

I think I remember Raptor running much slower on the a 486sx 25 compared to my machine, a 486dx 33. I think this was because the game waits for a vsync each frame, and the 486sx with its ISA graphics card was not able to draw everything in 50 fps. So the framerate dropped to 25 fps. When I switched down the details (no shadows for the planes), the game ran at the same speed on both machines...

If you're doing stuff under windows, you must know that there are also other processes than your game that require cpu time. Especially if they do disc accessing, it can seem as a jerky motion. For example, Winamp seems to be reason for jerkyness on my machine, so I close it before playing games.

You can also try to boost the priority of the process of your game. It's easy to test it by opening task manager and from the processes page right-click the game and set its priority to "above normal" or so. If it helps, you can do the priority adjustment automaticly in the software:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setpriorityclass.asp

I haven't tested this, but basicly it would go like (put it into the beginning of the program)

I would love this code if its what I think it is...

IM having frame rate locking issues myself. Though its cause im new to using a scrolling engine (Where the choppyness is now only apparent to me). Im not running this code on PC im running it on a console device (a mobile app actually)t hat should have really consistant frame rates, and it supposedly has a microtimer built in.

My current method of locking the frame rate still must not be working cause I do this:

Get start time
do all things: render, ai, get input
then wait_clock

" im running it on a console device (a mobile app actually)t hat should have really consistant frame rates"

Why do you think the PDA will have consistent frame rates?

I also often add simple blur to tick fetched from system.
Here's ad hoc example, is your technique anything like this?

My algorithm use a circular array, of adjustable size. The difference of the last and first entry is divided by the size.

The slow start problem you mention is solved by setting the size to 0 when it is initialized, then the size is increased each frame until it is MaxSize.

Simple.

I coded similar system a few years ago as well, which also tried to compensate for heavy frame rate changes by changing amount of samples used to give results.

But eventually I noticed that such solution didn't usually give much advantage compared to the simple blurring solution, so nowadays I usually just add the blur and be happy with that. :)