Message-Id: <199807280126.CAA04439@sable.ox.ac.uk> Comments: Authenticated sender is From: George Foot To: Dan Goodman Date: Tue, 28 Jul 1998 02:24:56 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Frame rate Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk CC: djgpp AT delorie DOT com Precedence: bulk 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