Re: [pygame] colorkey and time scale
Brendan Becker <tgz@...
2002-12-06 18:33:34 GMT
>Some sort of frame-rate control should probably be built in to your
>game. Notice that this is usually a _maximum_ framerate (which I
>never seem to hit on my 486
>If you do not have a control like this, the game will play at
>different speeds on different machines, and might be unplayably
>fast on systems much faster than the one on which you develop
>I am thinking now about how to deal with slower systems.... I guess
>if the framerate drops below the desired framerate, you might have
>a motion-multiplier to pseudo-speed things up to normal. You might
>run some sort of frame-rate test in the beginning of the game --
>during a demo or intro -- and use that throughout?
What I've found is most useful is to calculate the position based on what time it is. Although system clocks
vary in speed a LITTLE sometimes, you can generally rely on the system clock for a good guess at what time it
is, or how long your game has been running.
although it may not be easy at first to calculate positions of things based on time, and possible with every
game, if it works you don't have to worry about framerate limiting because the positions will
automatically just... be there.
For example, you will want to define how far in pixels an object moves in a certain amount of time, like, per
second, then calculate how many seconds it's been since the last frame, which will most likely be a
fraction of a second (don't forget to use floats!). Then, multiply that fraction by the per-second rate
and you have it moving almost exactly the right amount every frame. That way you don't even have to limit
your FPS, and everything always runs as smoothly as possible.
Granted, this will cause framedraws to happen on really fast machines even when they shouldn't, but still,