I''d say they probably lower the "wait" time for the next frame of animation. Say you have 10 choices for game speeds. At the slowest game speed, there is a 1 second delay between each frame of animation (this is a high number, but works for this explanation), meaning that it draws one frame, wait a second, draw the next... If it''s on level 2, then you can change the delay to 0.9 seconds, and all the way up to level 10 (fastest) where the delay is 0.1 seconds. Now these numbers are not actual numbers used, just ones I pulled out of my random number generator in my head . If you know a little about frame rates, and the stuff involved in that you should be able to take it from there. This is how I would probably do it, I don''t know if that''s what they do. Hope that helps.

----------------------------------------

I'm fat, you're ugly. I can lose weight.

------------------------------------

"We are the music makers, and the dreamers of the dreams."
- Willy Wonka

I don''t know about AoE, but in TA everything that is time-based is recorded per second. That way, nothing but the rate at which the "seconds" go by needs changing.

put the mouse over a unit and hit F1, it''ll show stats about turning rate PER SECOND and movement PER SECOND and acceleration per second PER SECOND. Then press and hold spacebar, and change the speed of the game. You''ll see that the "game time" counter speeds up as well.

I''m currently starting (...for the last 3 months) a RTS, but I''ve found that modify the distance a unit travels between frames can get really icky. The first problem is that at the lowest speed units still need to have a movement rate of 1 pixel/second, which means the game can only slow down so much. Reducing the actual framerate causes the game to become very jerky (scrolling, mousement), unless the lowest framerate is 25fps, in which case the highest gamespeed is likely impossible except for fast machines. This can also cause problems in multiplayer sync.

Using per second movement speed can also screw things up because of rounding. With enough distance 2 units with different speeds can depart from 2 points bound for a single third, on one speed the first gets there way ahead of the other, on another game speed they both get there at the same time (since the rounded per second speed is the same).

At the moment I''m using to seperate framerates to control movement. The drawing framerate just goes as fast as it can (to create the best framerate for mouse and scrolling). The second framerate is controlling how many times/second that the environment is doing game stuff (units moving, decrementing building times). When the draw rate is faster than the game rate the game stuff is only done on those draw frames when enough time has elapsed to account for one game frame. When the draw rate is slower is completes several game frames for each draw frame.

If you don''t understand what I just said (I don''t already) heres some "code"

variables: StartFrame and CurrentFrame are of Time (millisecond)
GameFrameLength is the milliseconds for 1 gameframe
function Time returns the current time
function DoGame executes one frame of the game
function DoDraw draws one frame


StartFrame = Time
repeat
CurrentFrame = Time
if (CurrentFrame-StartFrame>=GameFrameLength) {
repeat
DoGame
StartFrame=StartFrame+GameFrameLength
until (CurrentFrame-StartFrame)>GameFrameLength
}
DoDraw
until the Stop

quote: I''m currently starting (...for the last 3 months) a RTS, but I''ve found that modify the distance a unit travels between frames can get really icky. The first problem is that at the lowest speed units still need to have a movement rate of 1 pixel/second, which means the game can only slow down so much. Reducing the actual framerate causes the game to become very jerky (scrolling, mousement), unless the lowest framerate is 25fps, in which case the highest gamespeed is likely impossible except for fast machines. This can also cause problems in multiplayer sync.

I suggest you use floating point numbers for the position of the units, that way you can have speeds below 1. Besides, the movement looks smoother that way.

-Jussi

Have you tried storing your units locations using floats (or fixed points) instead of integers?

Then there would be no problem having units move 0.5 pixels per turn etc. Maybe you won''t need that separate control frame rate either if it''s only because of that problem.

-Ratsia

I have a unique and marvelously simple solution to this problem

int fps = 100; //target fps
LARGE_INTEGER CurrentTicks; //Last frame''s ending time
LARGE_INTEGER FrameDelay; //This frame''s starting time
float SpeedFactor; //how much to change movement due to frame rate

Now, every frame I call this function:
void SetSpeedFactor()
{
QueryPerformanceCounter(&CurrentTicks);
//This frame''s length out of desired length
SpeedFactor = (float)(CurrentTicks.QuadPart-FrameDelay.QuadPart)/(TicksPerSecond.QuadPart/fps);
if (SpeedFactor <= 0)
SpeedFactor = 1;
QueryPerformanceCounter(&FrameDelay);
}

So, I now have a float (SpeedFactor) that will vary in inverse proportion to the frame rate. So, if my target fps is 100 (as above) and actual is 30, SpeedFactor will be .3. Then I just multiply all my game''s movement by SpeedFactor. So, just by changing the fps variable, I can modify the entire game''s speed. This also takes care of faster/slower machines running at the same game speed.

Nifty, eh?



~BenDilts( void );