I’ve finaly almost finished my pong clone 
but it has one major bug. It
runs to fast on fast commputers. Is there any way I can make the speed of
the program Independent of the commputer
You can download the exe as well as the sorce code ate
www.geocities.com\gamegod3001\godpong.ZIP_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
In your main loop, at the point where you update the positions of all
your objects, you need to make this dependent on the time elapsed since
the last call.
Something like this:
Uint32 ticks = SDL_GetTicks();
while (true)
{
Uint32 this_ticks = SDL_GetTicks();
Uint32 elapsed = this_ticks - ticks;
ticks = this_ticks;
Update(elapsed);
}
Corey Struble wrote:>
I’ve finaly almost finished my pong clone
runs to fast on fast commputers. Is there any way I can make the speed of
the program Independent of the commputerYou can download the exe as well as the sorce code ate
www.geocities.com\gamegod3001\godpong.ZIP
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
I think this will help you out (if I’m wrong, don’t
flame me =)
Use SDL_GetTicks, like so:
//top of your code
Uint32 delay;
/be sure to initialize the timer (if you haven’t
already/
SDL_Init_Subsystem (SDL_INIT_TIMER);
//game loop
delay = SDL_GetTicks ();
//your game code
/this will force the game to wait the specified
amount of time until the next frame, where DELAYTIME
is the difference in milliseconds (eg, DELAYTIME==33
will make your game run at 30 FPS,DELAYTIME==16 at 60
FPS, etc/
while (SDL_GetTicks () - delay < DELAYTIME);
Actually, you shouldn’t just sit in the loop and do
nothing, but that’s just a simple example.
Hope this helps.
— Corey Struble wrote:> I’ve finaly almost finished my pong clone 
but it
has one major bug. It
runs to fast on fast commputers. Is there any way I
can make the speed of
the program Independent of the commputerYou can download the exe as well as the sorce code
ate
www.geocities.com\gamegod3001\godpong.ZIP
Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
=====
Michael Cowart
@Michael_Cowart
“Elen sila lumenn’ omentielvo”-a star shines on the hour of our meeting
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
I’ve finaly almost finished my pong clone
runs to fast on fast commputers. Is there any way I can make the speed of
the program Independent of the commputerYou can download the exe as well as the sorce code ate
www.geocities.com\gamegod3001\godpong.ZIP
http://lgdc.sunsite.dk/articles/22.html
“Making the game world independent of CPU speed”
-Erik <@Erik_Greenwald> [http://math.smsu.edu/~erik]
The opinions expressed by me are not necessarily opinions. In all probability,
they are random rambling, and to be ignored. Failure to ignore may result in
severe boredom or confusion. Shake well before opening. Keep Refrigerated.
Oh, jeez… this is the sort of thing that can cause major discussions… 
There’s actually a lot of different ways to accomplish this. One school of
thought (and this is probably used the most often) is to have some sort of a
waitframe function which sees how much time has elapsed since the last
frame-update. If not enough has elapsed, it burns the extra time via
SDL_Delay(…):
void waitframe(void)
{
static Uint32 next_tick = 0;
Uint32 this_tick;
/*
* Wait for the next frame
*/
this_tick = SDL_GetTicks();
if (this_tick < next_tick) {
SDL_Delay(next_tick - this_tick);
}
next_tick = this_tick + i*(1000 / fps);
}
(here, fps is roughly your requested Frames Per Second). Note that this will
give you different delay resolutions on differing platforms and differing
system loads.
Another school of thought (that I was introduced to by Olivier Dagenais on
this list) is where you perform some initial timing of certain blits, and
then scale the remainder of your animations according to that. This time you
work independent of frames, and instead focus on animation speed (for
example, if you have an object that you want to take 5 seconds to move across
the screen, or an animation that should loop after 1/2 seconds, you scale
your delays in order to achieve this). I don’t have a really good example of
this off the top of my head… but it shouldn’t be too difficult to come up
with.On Tuesday 04 September 2001 6:17pm, Corey Struble wrote:
I’ve finaly almost finished my pong clone
runs to fast on fast commputers. Is there any way I can make the speed of
the program Independent of the commputer
–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Tux4Kids: < http://www.geekcomix.com/tux4kids/ >
The latter has to be the best method, since the faster the computer the
’smoother’ the motion of the game objects will be.
If you hold the machine to a minimum loop time, you won’t get smoother
updates no matter how fast the computer is. Also, this will mean that the
game still simply runs SLOW on a fast computer, whereas if you multiply all
object motion by an update speed setting, you’ll get chunkier on a slow
computer, but everything will still move at the appropriate overall speed.
Oh, jeez… this is the sort of thing that can cause major discussions…
There’s actually a lot of different ways to accomplish this. One school of
thought (and this is probably used the most often) is to have some sort of
a
waitframe function which sees how much time has elapsed since the last
frame-update. If not enough has elapsed, it burns the extra time via
SDL_Delay(…):void waitframe(void)
{
static Uint32 next_tick = 0;
Uint32 this_tick;/* * Wait for the next frame */ this_tick = SDL_GetTicks(); if (this_tick < next_tick) { SDL_Delay(next_tick - this_tick); } next_tick = this_tick + i*(1000 / fps);}
(here, fps is roughly your requested Frames Per Second). Note that this
will
give you different delay resolutions on differing platforms and differing
system loads.Another school of thought (that I was introduced to by Olivier Dagenais on
this list) is where you perform some initial timing of certain blits, and
then scale the remainder of your animations according to that. This time
you
work independent of frames, and instead focus on animation speed (for
example, if you have an object that you want to take 5 seconds to move
across
the screen, or an animation that should loop after 1/2 seconds, you scale
your delays in order to achieve this). I don’t have a really good example
of
this off the top of my head… but it shouldn’t be too difficult to come u
p> with.–
Sam “Criswell” Hart AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Tux4Kids: < http://www.geekcomix.com/tux4kids/ >
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
— Rob Clayton wrote:
The latter has to be the best method, since the
faster the computer the
‘smoother’ the motion of the game objects will be.
Basically, the first method is FPS based, the second
is time based. The second method IS better, and If you
are doing a networked game, it is the only fair way to
work (if you use the FPS method, you would have to
sync to the slowest machine, but if you go time based,
things will stay synced no matter what (it just won’t
look as good on the slower machine)).=====
Michael Cowart
@Michael_Cowart
“Elen sila lumenn’ omentielvo”-a star shines on the hour of our meeting
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
—end quoted text—
can you tell me how I could make it be time based instead frame based?
thanks for helping!On Tue, Sep 04, 2001 at 09:20:24PM -0700, Michael Cowart wrote:
Basically, the first method is FPS based, the second
is time based. The second method IS better, and If you
are doing a networked game, it is the only fair way to
work (if you use the FPS method, you would have to
sync to the slowest machine, but if you go time based,
things will stay synced no matter what (it just won’t
look as good on the slower machine)).
–
Marcelo R Leitner
ICQ #: 29966851
can you tell me how I could make it be time based
instead frame based?
You basically do all the physics calculations in your
game based on actual time. As you might expect, this
is more difficult (well, not really) than just
updating every frame.
An example would definitely help here, so here you go-
(NOTE: It was really late when I wrote this, so if
there are any errors in my calculations, please don’t
take a sledgehammer to my head (a regular hammer will
be fine =)
Say you have a image of a ship, and you want to have
it move horizontally across a 800x600 screen in 4
seconds. First, you have to do some calculations.
Horizontal width of screen: 800 pixels
Total elapsed time: 4 seconds
Speed of ship (in pixels/second) = 800/4 = 200
pixels/second
equation relating distance, velocity, and time:
d=v*t
Now, for a bit of psuedo code
int posistion=0; /start at posistion 0/
float velocity=200; /our velocity/
Uint32 time_start; /our start time/
//get start time
time_start = SDL_GetTicks();
//now, the game loop
while(TRUE)
{
//game related stuff
/now, this is where we update the posistion of the
ship (note how I cast SDL_GetTicks to float, subtract
the start time, and divide by 1000 to convert
milliseconds into seconds, which gives us the elapsed
time since the start of the program in seconds)/
posistion =
velocity*(((float)SDL_GetTicks()-time_start)/1000);
//now draw the ship at it’s current posistion
}//end loop
//end psuedo code
Now, this is a ugly bit of code with a LOT of room for
optimization, but the ship will move across the screen
in 4 seconds, irrelevant of the framerate. If the
framrate is low ( <30 or so), the animation will be
jerky and the ship will seem to “skip” across the
screen, but it will still reach the other side in 4
seconds.
As you can see, it’s a lot of work. Probably for a
pong type of game, you would just like to lock the
framerate a a certain value, and not bother with a
time based physics model, but to be utterly realistic,
time based is the only way to go.=====
Michael Cowart
@Michael_Cowart
“Elen sila lumenn’ omentielvo”-a star shines on the hour of our meeting
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
You basically do all the physics calculations in your
game based on actual time. As you might expect, this
is more difficult (well, not really) than just
updating every frame.
I have no real experience with programming this type of thing, but
I’ve spent some time in the past thinking on this topic (differential
time programming).
I really find more difficult this kind of approach (whereas certainly
it’s better).
The points that I see troublesome are:
Non linear trajectories.
Variability of results.
As for 1), it seems to me that accurate computations will require some
type of integral calculation to be exact, when no simple formula is
avalaible which gives position as a function of time (like lines,
circunferences, elipses, etc).
This leads directly to 2). When fixed framerate, you know you will
always get the same results, even in the worst case when your game
slows down below desired framerate. Even if your computations aren’t
exact (as per real physics), deltaT is fixed so results are the same.
In the other hand, when time programming, if computations on complex
trajectories aren’t done accurately, the difference in deltaT will
lead to different results. Can be source of problems when big slow
downs (big time steps) or when accelerated play (like in simulators).
Also, small changes in dT when trajectories are very variable could
affect the overall result.
Maybe there are easy solutions to these topics, but my mathematical
knowledge isn’t very high and don’t see other way. Any comments will
be welcomed (maybe to my email, given that this is OT for SDL).
An example would definitely help here, so here you go-
You’re overcomplicating stuff… Here’s some code taken from
"Programming Linux Games" by Loki / John Hall (great book!):
/* Determine how many milliseconds have passed since
the last frame, and update our motion scaling. */
prev_ticks = cur_ticks;
cur_ticks = SDL_GetTicks();
time_scale = (double)(cur_ticks-prev_ticks)/30.0;
Where 30.0 is the framerate you’re working from, ie. no adjustments
for that framerate. Basically, you just do this every frame, and then
you only have to multiply any movements/calculations/etc by
time_scale. For example (again from PLG):
p->world_x += p->velocity * cos(angle*PI/180.0) * time_scale;
p->world_y += p->velocity * -sin(angle*PI/180.0) * time_scale;
p here is the player ship. The movement speed in x and y directions
are calculated out from a default of 30.0 FPS (from the time_scale
calculation), and then just multiplied with time_scale to scale it.
Easy, fast, and works great too!–
Trick
One simple (but less efficient) solution is to have your physics update occur
at 1 ms intervals, then when you have read SDL_GetTicks(), simply loop over
the delta time, thus calling the physics update code once for each
millisecond that has elapsed.
Any other granularity can be used as well, with the slight modification that
unused partial timeslices need to be accumulated until they fill up a
complete timeslice. For example, if your desired timeslice is 5 ms, and the
delta was 8, then run once, and keep the remaining 3 ms for the next time you
loop. So if the next delta was 4, you’d add the 3 to get a delta of 7. Then
run one update, and keep 2 ms for the next update.
-RayOn Wednesday 05 September 2001 05:30, you wrote:
You basically do all the physics calculations in your
game based on actual time. As you might expect, this
is more difficult (well, not really) than just
updating every frame.As for 1), it seems to me that accurate computations will require some
type of integral calculation to be exact, when no simple formula is
avalaible which gives position as a function of time (like lines,
circunferences, elipses, etc).This leads directly to 2). When fixed framerate, you know you will
always get the same results, even in the worst case when your game
slows down below desired framerate. Even if your computations aren’t
exact (as per real physics), deltaT is fixed so results are the same.In the other hand, when time programming, if computations on complex
trajectories aren’t done accurately, the difference in deltaT will
lead to different results. Can be source of problems when big slow
downs (big time steps) or when accelerated play (like in simulators).
Also, small changes in dT when trajectories are very variable could
affect the overall result.Maybe there are easy solutions to these topics, but my mathematical
knowledge isn’t very high and don’t see other way. Any comments will
be welcomed (maybe to my email, given that this is OT for SDL).
[…]
The points that I see troublesome are:
Non linear trajectories.
Variability of results.
Exacty. Collision detection and per-frame check state/perform action
control systems are especially troublesome.
Simply put; in a time based system, you have to trow away the idea of a
discrete timeline.
Or do you?
No! It’s perfectly possible to convert back and forth between the actual
frame rate and any other frame rate. You can just keep your "engine"
running at whatever frame rate you want, and then interpolate all actual
rendering coordinates between the last two frames generated by the engine.
From cs.h of Project Spitfire (now used in SKobo):
—8<----------------------------------------------------------------
typedef struct
{
/* 24:8 fixpoint values /
int x, y; / logic position */
int xv, yv;
int xa, ya;
} cs_vector_t;
typedef struct
{
/* 24:8 fixpoint values here as well */
cs_vector_t v;
int ox, oy; /* last position (for filtering) */
int gx, gy; /* graphic position */
/* (changed != 0) if gx or gy changed during the last update.
* This is a bit mask with the same format as the coords,
* which means that you can mask some low bits off to set
* a coarse movement sensitivity threshold.
* Ex. (changed & 0xffffff00) == "gx or gy moved to
* another pixel posn."
*/
int changed;
} cs_point_t;
---------------------------------------------------------------->8—
cs_vector_t is the part that the game engine should be concerned with.
(You may ignore the (xy,yv) and (xa,ya) pairs - they’re from the original
control system of PSF, which uses them to automatically manage speed and
acceleration. SKobo doesn’t use them at all.)
cs_point_t is used by the graphics engine to convert the “stream of
frames” from the game engine frame rate (fixed at 60 Hz for PSF and 30 Hz
for SKobo) to the screen frame rate (limited to the monitor refresh rate
where possible).
I’m just about to uploaded a test program for the SKobo graphics engine,
which demonstrates perfectly smooth animation with a control system frame
rate of 5 Hz (graphics from XKobo). It’ll be at
http://olofson.net/download/enginetest.tar.gz
in a few minutes.
It’s using an “old” version of the engine, which explains the cool "zoom"
bug when starting the program. All objects are insitialized at (0,0),
causing the engine to interpolate their movement to their real starting
positions over the first control system frame, which is 200 ms…
BTW, my latest hack of XKobo 1.11+ is on that site as well, just peel the
path off. Nothing special; just minor improvements of Izumo’s sound FX
engine.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 05 September 2001 11:30, A. R. Mosteo Chagoyen wrote:
[…]
Maybe there are easy solutions to these topics, but my mathematical
knowledge isn’t very high and don’t see other way. Any comments will
be welcomed (maybe to my email, given that this is OT for SDL).One simple (but less efficient) solution is to have your physics update
occur at 1 ms intervals, then when you have read SDL_GetTicks(), simply
loop over the delta time, thus calling the physics update code once for
each millisecond that has elapsed.Any other granularity can be used as well, with the slight modification
that unused partial timeslices need to be accumulated until they fill
up a complete timeslice. For example, if your desired timeslice is 5
ms, and the delta was 8, then run once, and keep the remaining 3 ms for
the next time you loop. So if the next delta was 4, you’d add the 3 to
get a delta of 7. Then run one update, and keep 2 ms for the next
update.
Yeah, that’s basically what I do in the Spitfire/SKobo engine, although I
set the physics frame rate so that it’s normally lower than the video
frame rate on the average target system.
Then I just add linear interpolation over the last two sets of object
coordinates generated by the physics/control code, so that animation will
be smooth even if the video frame rate exceeds the control system frame
rate.
The interpolation also practically eliminates the interference effects
you’d otherwise get when the two frame rates are close, but not identical.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 05 September 2001 15:18, Ray Kelm wrote:
The method I prefer is to maintain a global time_scale variable (floating
point) and set this each frame based on a weighted average of how long it
took to render the previous few frames, scaled against some standard (like
30fps). Every animation and movement in the game is scaled against this
variable. For instance, if you’ve adjusted your movements to look good at
30fps, and the game is actually running at about 60fps, then time_scale
will be approximately 0.5, and all movements will be halved.
This is close to the second method described below, but a bit different I
think.
Advantages of this approach:
-No forced delays; your framerate is as high as possible (however, if you
do choose to add a framerate limiter, this algorithm will adjust itself)
-Since time_scale is a weighted average, a quick spike in system
performance (fairly common) won’t affect the game too much
-time_scale is a ratio against a fixed framerate (usually 30fps), so you
can tune your animations regardless of the rendering speed of the end-user’
s computer.
See the Penguin Warrior example code (http://www.nostarch.com/plg_updates.
htm) for an implementation.
-JohnOn Tuesday, September 4, 2001, at 10:14 PM, Samuel Hart wrote:
On Tuesday 04 September 2001 6:17pm, Corey Struble wrote:
I’ve finaly almost finished my pong clone
runs to fast on fast commputers. Is there any way I can make the speed
of
the program Independent of the commputerOh, jeez… this is the sort of thing that can cause major discussions…
There’s actually a lot of different ways to accomplish this. One school of
thought (and this is probably used the most often) is to have some sort
of a
waitframe function which sees how much time has elapsed since the last
frame-update. If not enough has elapsed, it burns the extra time via
SDL_Delay(…):void waitframe(void)
{
static Uint32 next_tick = 0;
Uint32 this_tick;/* * Wait for the next frame */ this_tick = SDL_GetTicks(); if (this_tick < next_tick) { SDL_Delay(next_tick - this_tick); } next_tick = this_tick + i*(1000 / fps);}
(here, fps is roughly your requested Frames Per Second). Note that this
will
give you different delay resolutions on differing platforms and differing
system loads.Another school of thought (that I was introduced to by Olivier Dagenais on
this list) is where you perform some initial timing of certain blits, and
then scale the remainder of your animations according to that. This time
you
work independent of frames, and instead focus on animation speed (for
example, if you have an object that you want to take 5 seconds to move
across
the screen, or an animation that should loop after 1/2 seconds, you scale
your delays in order to achieve this). I don’t have a really good example
of
this off the top of my head… but it shouldn’t be too difficult to come
up
with.–
Sam “Criswell” Hart AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Tux4Kids: < http://www.geekcomix.com/tux4kids/ >
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
John R. Hall | Overfull \brain has occurred while \learn is active
CS Student - Georgia Tech | Author - Programming Linux Games
Unsolicited commerical e-mail will be considered an act of war.
Hi David,
So will you be using the same engine for SpitFire and SKobo?
When are we likely to see some screen shots of SpitFire?
thanks,
Dominique
http://www.DelphiGamer.com := for all your Delphi/Kylix game development
needs;
David Olofson wrote:> On Wednesday 05 September 2001 15:18, Ray Kelm wrote:
[…]
Maybe there are easy solutions to these topics, but my mathematical
knowledge isn’t very high and don’t see other way. Any comments will
be welcomed (maybe to my email, given that this is OT for SDL).One simple (but less efficient) solution is to have your physics update
occur at 1 ms intervals, then when you have read SDL_GetTicks(), simply
loop over the delta time, thus calling the physics update code once for
each millisecond that has elapsed.Any other granularity can be used as well, with the slight modification
that unused partial timeslices need to be accumulated until they fill
up a complete timeslice. For example, if your desired timeslice is 5
ms, and the delta was 8, then run once, and keep the remaining 3 ms for
the next time you loop. So if the next delta was 4, you’d add the 3 to
get a delta of 7. Then run one update, and keep 2 ms for the next
update.Yeah, that’s basically what I do in the Spitfire/SKobo engine, although I
set the physics frame rate so that it’s normally lower than the video
frame rate on the average target system.Then I just add linear interpolation over the last two sets of object
coordinates generated by the physics/control code, so that animation will
be smooth even if the video frame rate exceeds the control system frame
rate.The interpolation also practically eliminates the interference effects
you’d otherwise get when the two frame rates are close, but not identical.//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi David,
So will you be using the same engine for SpitFire and SKobo?
Yes, at least the lower levels. (SKobo uses a C++ wrapper with added
features such as windows to support the logic of the old game engine.
Spitfire is more data oriented and now has a scripting language that
could be seen as a wrapper.)
When are we likely to see some screen shots of SpitFire?
Well, I can upload some screenshot right away, at least from the Win16
port of the old version. The SDL version isn’t doing very much right now,
as the scripting engine isn’t finished, but all versions look identical
so far.
Scripting language!? Well, it started out with moving various hardcoded
stuff into text format config files, and then I just couldn’t stay away
from bison. Not sure if I’ll keep it, or throw it out again - I’ll
decide when I’ve released SKobo.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 06 September 2001 10:45, Dominique Louis wrote:
Ok, thanks!
I really appreciate both methods!!
[]'s–
Marcelo R Leitner
ICQ #: 29966851
Ok! Thanks!
I’ve appreciated any help you all gave to me!
[]'s–
Marcelo R Leitner
ICQ #: 29966851