Mail Archives: djgpp/1998/07/27/21:27:10
On 25 Jul 98 at 6:29, Dan Goodman wrote:
> I don't know if this question would be better directed to
> rec.games.programmer, but that seems to have degenerated into DirectX and 3D
> recently.
That's not much of an excuse ;). You could have asked this question
on the Allegro Game Programming mailing list, if you're subscribed
to that. I think you subscribe by sending a message to
listserv AT canvaslink DOT com, containing "subscribe agp Dan Goodman" in
the message body. The address of the mailing list is
agp AT canvaslink DOT com.
> Does anyone know of a neat way to make sure the game runs at the right speed
> regardless of the speed of the computer. Currently, my game runs at 1000fps
> if I use dirty rectangles, but 30fps with double buffering, so it is
> currently on double buffering so I can actually see what happens, otherwise
> the players just disappear of the screen the moment I touch a button.
The topic is discussed in Allegro Vivace
(http://www.canvaslink.com/gfoot/vivace) and in the "Allegro
FAQ/Coding Techniques" page (http://www.canvasnet.com/allegro/faq/).
Please look there for more information.
> Currently my game loop looks like this:
>
> do{
> Get player input
> Move players etc..
> Draw frame
> }
The most important thing you need to do is to divorce the frame rate
from the game cycle rate. There's normally absolutely nothing wrong
with getting 1000 FPS -- most people would be overjoyed.
Ultimately it doesn't matter too much how consistent the frame rate
is; obviously it's nicer to watch something with a higher frame
rate, but not everybody has the same hardware, so it's not realistic
to expect everyone to get the same frame rate. It is important,
however, that the game cycle rate (i.e. the speed of the action in
the game) is constant.
> I was thinking that maybe you could store two copies of all the parameters
> that drawing the frame needs. Then you could have the draw frame bit as the
> main loop, and call the get player input and move players on a timer 50
> times per second (for instance) and use one set of parameters for the
> input/move players bits, then copy that set into the other set before
> drawing each frame. But I think this would only work if your frame rate was
> higher than necessary, any ideas for a method which would work whatever the
> speed of the computer (i.e. too slow OR too fast)? The Allegro demo seems to
> have something like this in it, but without any specific documentation for
> it, I can't work it out.
You're on the right lines, but it's not sensible to do all of your
game logic in a timer callback, and some things (such as polling the
joystick, at least in Allegro 3.0) aren't strictly safe things to do
in the timer callback, since the routines are not locked. Also
you're on the verge of multi-threaded programming, which requires a
bit more thought.
It's best to make set timer running at your desired game cycle rate,
and make that timer routine just increment a variable. Then you can
read off the value of that variable in your game loop:
do {
draw_one_frame();
if (target_game_cycle > current_game_cycle) {
get_input();
process_one_game_cycle();
current_game_cycle++;
}
} while (...);
Some people prefer to use "if (variable) { ...; variable--; }"
instead; this has some advantages. See the documents I referred to
earlier for more information, and explanations of why this has almost
the same effect as the system you described above.
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
- Raw text -