Not logged in, Join Here! or Log In Below:  
News Articles Search    

 Home / Game Design & Programming / 2D Motion, time stepping and old games... Account Manager
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

December 20, 2004, 08:52 AM

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.


December 20, 2004, 10:30 AM

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.


December 20, 2004, 05:25 PM

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. :)

Anthony Bowyer-Lowe

January 10, 2005, 02:29 AM

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.

Victor Widell

January 11, 2005, 01:05 PM

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...


January 11, 2005, 02:12 PM

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


January 11, 2005, 03:57 PM

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...

Sampsa Lehtonen

January 12, 2005, 03:26 AM

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:

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

  2. SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS);

You can also try other priorities, but do remember that for example REALTIME_PRIORITY_CLASS will hog every cpu cycle it can get, and if your game gets into a infinite loop, it is very very hard to kill it using task manager. So be sure your game works like charm before doing that :)


February 15, 2005, 01:22 PM

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

Victor Widell

February 15, 2005, 07:39 PM

" 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?

Jetro Lauha

February 16, 2005, 06:55 AM

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

  2. // app init:
  3. startTick = GetTickCount();
  5. // in update loop:
  6. tick = ((GetTickCount() - startTick) + lastTick * 3) / 4;
  7. lastTick = tick;

This mixes 25% of the actual tick value each frame to the used tick. Provided that the frame rate doesn't jump up and down all the time, this works pretty nice in my experience. Usually I use either 50%-50% or 25%-75%, but I have used some more extreme ones as well - if you increase the ratio a lot, you'll get a slight "slow start" in the time values. Here's an applet demonstrating this: (also with source:

Some buffered average time value schemes w/self adjusting for framerate changes etc haven't worked better. And with low-level code based solutions (rdtsc, QueryPerformanceCounter etc) you need to take the headache of taking account of features like CPU speedstepping etc.

Victor Widell

February 16, 2005, 07:17 PM

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.


Jetro Lauha

February 17, 2005, 04:47 AM

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. :)

This thread contains 13 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.