Stuck with multiplayer and some segfaults

hey guys,

i thought maybe you could give me one hint or another on some probs with the
following program of mine:
last week i played some sort of 3d-pong game on a website which was really
fun. it was actually so much fun, that i decided to make one myself with a
two-player network-mode. each player controls a pad at the end of a tunnel in
which a ball bounces. obviously the goal is to shoot the ball out of the
tunnel on the opponent’s side (consider yourself a goalie, too).

i got i all worked out now and a basic solo-player mode works like a charm on
linux systems (quite addicting, already), but now i have some problems
concerning program logic and net-code.
i’m kinda stuck in finding the best server<->client system, and so on.

also, a friend of mine tried to compile my version with VC++ and windows.
apparently the prog crashes right after startup (dlls loaded an’ all).

since the program will be open sourced i’d really appreciate somebody
reviewing the code, maybe giving some hints on how to structure the whole
thing (as you will notice, i’m not used to programming c++).

i really am quite keen on the idea (although it’s not the first 3d-pong out
there).

there are also some minor issues like that i originally planned to make
"bending" the ball a great feature which then failed terribly because i
wasn’t able to find any formula for the ball-movement).
and last but not least my “3d-engine” cant change the camera position (which i
need to do in two-player mode)

you can find the source-code and a linux executable here:
http://j03.de/~jonas/bender.tar.gz and
http://j03.de/~jonas/bender.zip

take care … (excuse my english :wink: )–
Jonas Huckestein

Pub. PGP Key: http://pgp.upb.de:11371/pks/lookup?op=get&search=0xD2BAE645

"There was once a cross-eyed teacher who couldn’t control his pupils."
Another one: “I was wondering why the baseball kept getting bigger. Then it
hit me.” and “A bicycle can’t stand on its own. It’s two-tired.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050310/7b0f91cf/attachment.pgp

[…]

there are also some minor issues like that i originally planned to
make “bending” the ball a great feature which then failed terribly
because i wasn’t able to find any formula for the ball-movement).
[…]

I think you need to turn to aerodynamics for that one - and you need
to simulate ball spin too, if you aren’t already.

Some links explaining the phenomenon:
http://carini.physics.indiana.edu/E105/spinning-balls.html
http://www.soccerballworld.com/Physics.htm
http://www.golfjoy.com/golf_physics/dynamics.asp

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Thursday 10 March 2005 23.14, Jonas Huckestein wrote:

Or if it’s Curve Ball
(http://www.fetchfido.co.uk/games/curve_ball/curve_ball.htm) you’re
trying to implement, a Newton-style constant acceleration applied each
frame is enough =)

And if that’s the game you’re doing, inform me when you’re done!On Fri, Mar 11, 2005 at 01:45:19AM +0100, David Olofson wrote:

On Thursday 10 March 2005 23.14, Jonas Huckestein wrote:
[…]

there are also some minor issues like that i originally planned to
make “bending” the ball a great feature which then failed terribly
because i wasn’t able to find any formula for the ball-movement).
[…]

I think you need to turn to aerodynamics for that one - and you need
to simulate ball spin too, if you aren’t already.


Petri Latvala
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050311/df162ceb/attachment.pgp

hey guys,
thx for the fast responses, i knew you could help me.

Petri Latvala wrote:

I think you need to turn to aerodynamics for that one - and you need
to simulate ball spin too, if you aren’t already.
well, that was the problem, but thanx to davids links it’ll work out soon
enough :smiley:

Or if it’s Curve Ball
(http://www.fetchfido.co.uk/games/curve_ball/curve_ball.htm) you’re
trying to implement, a Newton-style constant acceleration applied each
frame is enough =)
i don’t really like a “per frame” acceleration because then the game differs
greatly on different machines with different framerates.

what still remains now is the net-code. i came to the conclusion, that it is
best to have on server which does all the calculating stuff and one client
which simply receives udp-packages, sends it’s own ball-position and then
draw’s the scene. only problem with that is, that the server is supposed to
be faster than the client.

and one more problem cameup: interface design and main menu and stuff. since
i’ve never done a game before i have no idea of such. i’d really greatly
appreciate help on this one :slight_smile:

take care …


Jonas Huckestein

Pub. PGP Key: http://pgp.upb.de:11371/pks/lookup?op=get&search=0xD2BAE645

"There was once a cross-eyed teacher who couldn’t control his pupils."
Another one: “I was wondering why the baseball kept getting bigger. Then it
hit me.” and “A bicycle can’t stand on its own. It’s two-tired.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050311/1c64ab7e/attachment.pgp

[…]

Or if it’s Curve Ball
(http://www.fetchfido.co.uk/games/curve_ball/curve_ball.htm)
you’re trying to implement, a Newton-style constant acceleration
applied each frame is enough =)
i don’t really like a “per frame” acceleration because then the game
differs greatly on different machines with different framerates.

Then you’re doing the maths wrong. Just like velocity, acceleration
must be “scaled” with the delta time. (And no, you can’t do that by
multiplying acceleration by delta time.)

Because of the complexity that adds, and other, more serious issues
(collision detection and event handling), I generally prefer to use a
fixed logic frame rate for totally concistent behavior. Not sure if
that’s the way to go for this type of game (physics centric), but
OTOH, with a sufficiently high logic frame rate, there is no
practical difference.

what still remains now is the net-code. i came to the conclusion,
that it is best to have on server which does all the calculating
stuff and one client which simply receives udp-packages, sends it’s
own ball-position and then draw’s the scene. only problem with that
is, that the server is supposed to be faster than the client.

Faster…? It’s usually the client that burns more cycles, due to the
graphics - except when one client is also the server, of course. I
don’t think that should matter in a game with approximately three
objects to keep track of, though. :slight_smile:

and one more problem cameup: interface design and main menu and
stuff. since i’ve never done a game before i have no idea of such.
i’d really greatly appreciate help on this one :slight_smile:

Well, a user interface for a game could be anything from a message
saying “PRESS SPACE TO PLAY!” + corresponding event handling logic,
through something like your average application GUI, based on Qt,
GTK+, some native widget set or whatever.

Anyway, in most cases, one should probably just try to keep it as
clean and simple as possible. Try to design a GUI that does what you
need with a minimum of confusing “bonus features”.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Friday 11 March 2005 07.42, Jonas Huckestein wrote:

thanks david :slight_smile:

Because of the complexity that adds, and other, more serious issues
(collision detection and event handling), I generally prefer to use a
fixed logic frame rate for totally concistent behavior.
yea, that’s what i was thinking. so how would i do that then?
simply skip a few rounds on my game-loop or do any problems come with that?
(theres this sdl_framerate thingy from the sdl_gfx package and i was
wondering why that is necessary at all)

Faster…? It’s usually the client that burns more cycles, due to the
graphics - except when one client is also the server, of course.
that’s the case :slight_smile:

Anyway, in most cases, one should probably just try to keep it as
clean and simple as possible. Try to design a GUI that does what you
need with a minimum of confusing “bonus features”.
i’ll do my best, thanks

take care …On Friday 11 March 2005 09:02, David Olofson wrote:

Jonas Huckestein

Pub. PGP Key: http://pgp.upb.de:11371/pks/lookup?op=get&search=0xD2BAE645

"There was once a cross-eyed teacher who couldn’t control his pupils."
Another one: “I was wondering why the baseball kept getting bigger. Then it
hit me.” and “A bicycle can’t stand on its own. It’s two-tired.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050311/811e741a/attachment.pgp

thanks david :slight_smile:

Because of the complexity that adds, and other, more serious
issues (collision detection and event handling), I generally
prefer to use a fixed logic frame rate for totally concistent
behavior.
yea, that’s what i was thinking. so how would i do that then?
simply skip a few rounds on my game-loop or do any problems come
with that?

That’s basically it. You decide on a nominal frame rate for your game
logic, and then you design all logic code as if that was the frame
rate of the game - like in the old days, when you’d normally
hard-sync the whole game to the display refresh rate. (Which was/is
either 50 or 60 Hz on devices made to be used with a TV set.) Then
you implement some logic to run the game logic at that average
frame rate, with a (sort of) asynchronous relation to the rendering
loop.

Note that you’ll need to be able to do both more and less than one
logic frame per rendered frame! If you decide on 100 Hz logic rate
for example, you’ll need to handle both lower and higher rendering
frame rates.

The next stage is optional, but rather nice: Implement interpolation
of all coordinates extracted from the logic code. That is, if logic
time turns out to be halfway between two logic frames when it’s time
to render, interpolate over the output from last two logic frames you
have, rather than just using the last one.

Have a look at my Fixed Rate Pig example, which demonstrates “ultra
smooth” animation while using a very low, fixed logic frame rate:
http://olofson.net/examples.html

(Or look at Kobo Deluxe, which uses the same technique - though I
suspect you won’t find that code as friendly to study. :wink:

(theres this sdl_framerate thingy from the sdl_gfx package and i was
wondering why that is necessary at all)

Haven’t looked that close at it, but I’d guess it’s just a handy tool
for measuring and/or throttling the frame rate, and/or for doing
these frame delta time calculations we all do one way or another…

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Friday 11 March 2005 12.23, Jonas Huckestein wrote:

On Friday 11 March 2005 09:02, David Olofson wrote:

Say you fix your logic rate to 100 Hz, that is 10 ms per frame. Try to
find as accurate as possible a time measurement, SDL_GetTicks() has 10
ms granularity so it is not ideal but might prove good enough at least
it won’t “drift” as time goes by. The trick is to keep a variable for
your current “logic time” or “game time”, which tries to “follow” the
computer time / real time as good as possible. Call it gameTime_ms, ms
for milliseconds:

In the main loop:

  1. process events,
  2. int computerTime_ms = getCurrentTime_ms(); // or whatever you call
    your routine
  3. // Now bring gameTime_ms up to the actual time!
    while(computerTime_ms-gameTime_ms > 0) {
    take a 10ms physic step
    gameTime_ms += 10;
    }
    4.draw graphics (a snapshot of the game state at gameTime_ms!)

So after the while-loop gameTime_ms will be 0-9 ms “before” the
computers actual time, but this is unnoticible for a human eye and
makes no physical difference AFAICS.

The processing of the events might be done in a separate thread to
enable granularity higher than the FPS rate! It might be a bit tricky
though maybe someone can fill up on this.

Another issue is the limited size of the gameTime_ms. If it is
unsigned 32bit, we get approx. 410^9 ms = 410^6 s = 410 / (6060) h
~= 4.400 hrs ~= 180 days. How long can a pong game get? :slight_smile: Anyway you
must make sure getCurrentTime_ms() starts counting at 0 when the
program boots…

/OlofOn Fri, 11 Mar 2005 12:23:09 +0100, Jonas Huckestein <jonas.huckestein at web.de> wrote:

thanks david :slight_smile:

On Friday 11 March 2005 09:02, David Olofson wrote:

Because of the complexity that adds, and other, more serious issues
(collision detection and event handling), I generally prefer to use a
fixed logic frame rate for totally concistent behavior.
yea, that’s what i was thinking. so how would i do that then?
simply skip a few rounds on my game-loop or do any problems come with that?
(theres this sdl_framerate thingy from the sdl_gfx package and i was
wondering why that is necessary at all)

Faster…? It’s usually the client that burns more cycles, due to the
graphics - except when one client is also the server, of course.
that’s the case :slight_smile:

Anyway, in most cases, one should probably just try to keep it as
clean and simple as possible. Try to design a GUI that does what you
need with a minimum of confusing “bonus features”.
i’ll do my best, thanks

take care …

Jonas Huckestein

Pub. PGP Key: http://pgp.upb.de:11371/pks/lookup?op=get&search=0xD2BAE645

"There was once a cross-eyed teacher who couldn’t control his pupils."
Another one: “I was wondering why the baseball kept getting bigger. Then it
hit me.” and “A bicycle can’t stand on its own. It’s two-tired.”


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Say you fix your logic rate to 100 Hz, that is 10 ms per frame. Try
to find as accurate as possible a time measurement, SDL_GetTicks()
has 10 ms granularity

SDL_GetTicks() has 1 ms granularity everywhere, except possibly on
some “broken” platform. (IIRC, there was some issue with WinNT, until
SDL had a workaround for it.) Most platforms have some call that
delivers sub-ms accurate timestamps.

It’s the scheduling (that is, SDL timers) that has 10 granularity on
most platforms.

so it is not ideal but might prove good enough
at least it won’t “drift” as time goes by. The trick is to keep a
variable for your current “logic time” or “game time”, which tries
to “follow” the computer time / real time as good as possible.

Yep, good point. You need to do that whether or not timestamps are ms
accurate, because ms granularity is just not suficient unless you get
very low frame rates.

[…]

The processing of the events might be done in a separate thread to
enable granularity higher than the FPS rate! It might be a bit
tricky though maybe someone can fill up on this.

Should work, though you have to timestamp events as they come in, and
enqueue them for actual processing in the game logic code, or you
might as well just process all events first thing every rendering
loop cycle.

Of course, this adds to latency - though in most cases, constant
latency is better than random jitter, even when significantly higher.

That said, I don’t think it matters much unless you get very low
frame rates - and then you can’t play the game anyway… Timestamped
input events might help to make mouse tracking smoother, though - but
only if the timestamps are more accurate than the rendering frame
rate. (So as long as SDL’s 100 Hz event loop is inbetween you and the
input API, it’s not going to help much.)

Another issue is the limited size of the gameTime_ms. If it is
unsigned 32bit, we get approx. 410^9 ms = 410^6 s = 410 / (6060)
h ~= 4.400 hrs ~= 180 days. How long can a pong game get? :slight_smile:
Anyway you must make sure getCurrentTime_ms() starts counting at 0
when the program boots…

…or base all game logic on delta times, with wrap safe delta time
calculations. (Pretty trivial with integers.)

Note that with fixed rate logic, you can use simple integer counters
(counting logic frames) to keep track of object life times and the
like. Doesn’t get any simpler than that. :slight_smile:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Friday 11 March 2005 13.14, Olof Bjarnason wrote:

Everytime fixed rate logic gets mentioned on this list (i.e., every few
days ;), I get more interested.

The only problem is, I tried both Fixed Rate Pig and Kobo Deluxe, and they do
NOT run entirely smoothly on my system (Dell Inspiron 8600 Laptop, Pentium M
1.6 GHz), 512 MB RAM, 64 MB GeForce FX Go5200 running at 60Hz, Debian Sid,
KDE using the official Nvidia drivers). The effect is most noticeable on
Kobo, which gives an obvious jerk every few seconds, both in SDL and OpenGL
modes (with GL vblank waiting enabled). Pig (and the smooth scrolling
example) run much smoother, but when paying attention, I still notice minor
jerks (like single frame skips perhaps) every few seconds.

Now perhaps it’s just my system setup, but other games seem to run fine,
including my own, which as far as I can tell seems to run absolutely
smoothly, with OpenGL, but using the same framerate for the game logic as I
get with GL flips, i.e. 60Hz, and using simple linear scaling for the game
logic. For the current game (a simple vertical scrolling 2D asteroid shooter)
that’s not so much of a problem, since it seems to run fine on different
systems and doesn’t have complex maths or anything, but an older (and as of
yet unfinished) 3D racing game had serious problems with collision detection
and our acceleration function (again, simply scaled by the GL framerate
delay), which might be solved by converting to a fixed rate logic.

Any additional insights or tips would be helpful. :slight_smile:

Thx,
Marian.On Friday 11 March 2005 12:55, David Olofson wrote:

Have a look at my Fixed Rate Pig example, which demonstrates “ultra
smooth” animation while using a very low, fixed logic frame rate:
http://olofson.net/examples.html

(Or look at Kobo Deluxe, which uses the same technique - though I
suspect you won’t find that code as friendly to study. :wink:


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.

Well of course fixed frame rate might seem jerky to the trained eye,
compared to “floating deltas”, if you look at a ball or something
moving at a constant speed over the screen or the prime example,
scrolling text, since every now and then there is one more or one less
logic step taken between to consequtive graphics frames:

Let’s say we have 100 Hz game logic, and 60 Hz gfx. Then there are
100/60 ~= 1.67 logic frames per graphic update. Then somethimes there
will be two logic updates between two graphic frames, and sometimes
one. Now when I come to think of it like this I’m not so sure I would
use dt = 10 ms (100 Hz) fixed logic frame rate since this WILL look
jerky :slight_smile:

Then again, increasing the logic frame rate to 1000 Hz will look much
smoother, but now we might start considering the computational amount
needed to take the physics steps that many times per “game time step”
… hmm. With a simple game physic/logic or very few objects, like in
the pong game discussed earlier today, that might be feasible, but I’m
not so sure in a many-many object game.

Interesting discussion!

/OlofOn Fri, 11 Mar 2005 19:12:08 +0100, Marian Schedenig <m.sched at gmx.at> wrote:

On Friday 11 March 2005 12:55, David Olofson wrote:

Have a look at my Fixed Rate Pig example, which demonstrates “ultra
smooth” animation while using a very low, fixed logic frame rate:
http://olofson.net/examples.html

(Or look at Kobo Deluxe, which uses the same technique - though I
suspect you won’t find that code as friendly to study. :wink:

Everytime fixed rate logic gets mentioned on this list (i.e., every few
days ;), I get more interested.

The only problem is, I tried both Fixed Rate Pig and Kobo Deluxe, and they do
NOT run entirely smoothly on my system (Dell Inspiron 8600 Laptop, Pentium M
1.6 GHz), 512 MB RAM, 64 MB GeForce FX Go5200 running at 60Hz, Debian Sid,
KDE using the official Nvidia drivers). The effect is most noticeable on
Kobo, which gives an obvious jerk every few seconds, both in SDL and OpenGL
modes (with GL vblank waiting enabled). Pig (and the smooth scrolling
example) run much smoother, but when paying attention, I still notice minor
jerks (like single frame skips perhaps) every few seconds.

Now perhaps it’s just my system setup, but other games seem to run fine,
including my own, which as far as I can tell seems to run absolutely
smoothly, with OpenGL, but using the same framerate for the game logic as I
get with GL flips, i.e. 60Hz, and using simple linear scaling for the game
logic. For the current game (a simple vertical scrolling 2D asteroid shooter)
that’s not so much of a problem, since it seems to run fine on different
systems and doesn’t have complex maths or anything, but an older (and as of
yet unfinished) 3D racing game had serious problems with collision detection
and our acceleration function (again, simply scaled by the GL framerate
delay), which might be solved by converting to a fixed rate logic.

Any additional insights or tips would be helpful. :slight_smile:

Thx,
Marian.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Let’s say we have 100 Hz game logic, and 60 Hz gfx. Then there are
100/60 ~= 1.67 logic frames per graphic update. Then somethimes there
will be two logic updates between two graphic frames, and sometimes
one.

Ok. I thought since it seems to be an often-used technique, interpolation
would reduce the effect so much that it isn’t noticeable (unfortunately, my
own eyes are quite trained in recognising this, since I’ve been trying to get
another computer to smoothly play DVDs on projector for months…)

Then again, increasing the logic frame rate to 1000 Hz will look much
smoother, but now we might start considering the computational amount
needed to take the physics steps that many times per “game time step”

I haven’t yet looked at the interpolation details, but isn’t the whole point
of interpolation not having to use too high logic rates? 1000 Hz sounds
awfully high for a more complex game (and I guess it would be difficult to
time as well, with SDL_Delay having “only” 1ms resolution and a draw routine
that will take longer than 1ms).

Marian.On Friday 11 March 2005 19:59, Olof Bjarnason wrote:


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.

yea, that’s what i was thinking. so how would i do that then?
simply skip a few rounds on my game-loop or do any problems come with that?
(theres this sdl_framerate thingy from the sdl_gfx package and i was
wondering why that is necessary at all)

Hi

I think you should check out this link… and what’s hiding behind it (especially Fix your timestep! page): ttp://www.gaffer.org:8080/articles/

HTH :slight_smile:

Koshmaar

Well of course fixed frame rate might seem jerky to the trained eye,
compared to “floating deltas”, if you look at a ball or something
moving at a constant speed over the screen or the prime example,
scrolling text, since every now and then there is one more or one less
logic step taken between to consequtive graphics frames:

Let’s say we have 100 Hz game logic, and 60 Hz gfx. Then there are
100/60 ~= 1.67 logic frames per graphic update. Then somethimes there
will be two logic updates between two graphic frames, and sometimes
one. Now when I come to think of it like this I’m not so sure I would
use dt = 10 ms (100 Hz) fixed logic frame rate since this WILL look
jerky :slight_smile:

Then again, increasing the logic frame rate to 1000 Hz will look much
smoother, but now we might start considering the computational amount
needed to take the physics steps that many times per “game time step”
… hmm. With a simple game physic/logic or very few objects, like in
the pong game discussed earlier today, that might be feasible, but I’m
not so sure in a many-many object game.

I’ve done it both ways, relative deltas based on the real elapsed time
and fixed deltas with as many steps as you need between frames. The math
is a little harder with relative deltas, but the computational cost is
the same for each frame and it is approximately equal to the cost of
computing the update for a fixed logic frame. So, if you are doing 1.67
(100 Hz) or 16.67 (1000 Hz) or what ever number of fixed increment
updates you are spending roughly 1.67 or 16.67 times as much computing
power between visible frames as the relative deltas technique does for
the same frame. In other words, you are potentially wasting a lot of CPU
cycles that you could be spending on game play.

Another interesting thing, at lest to me, is that the fixed delta scheme
is basically using an iterative technique to approximate the same result
that the floating deltas produces. But, the floating deltas technique
gets the exact (within floating point accuracy) result while the fixed
delta technique gets only an approximation. Sort of like the difference
between evaluating an integral over a range by solving the integral and
evaluating it versus using an iterative numeric method to get the number
you want.

	Bob PendletonOn Fri, 2005-03-11 at 19:59 +0100, Olof Bjarnason wrote:

Interesting discussion!

/Olof

On Fri, 11 Mar 2005 19:12:08 +0100, Marian Schedenig <m.sched at gmx.at> wrote:

On Friday 11 March 2005 12:55, David Olofson wrote:

Have a look at my Fixed Rate Pig example, which demonstrates “ultra
smooth” animation while using a very low, fixed logic frame rate:
http://olofson.net/examples.html

(Or look at Kobo Deluxe, which uses the same technique - though I
suspect you won’t find that code as friendly to study. :wink:

Everytime fixed rate logic gets mentioned on this list (i.e., every few
days ;), I get more interested.

The only problem is, I tried both Fixed Rate Pig and Kobo Deluxe, and they do
NOT run entirely smoothly on my system (Dell Inspiron 8600 Laptop, Pentium M
1.6 GHz), 512 MB RAM, 64 MB GeForce FX Go5200 running at 60Hz, Debian Sid,
KDE using the official Nvidia drivers). The effect is most noticeable on
Kobo, which gives an obvious jerk every few seconds, both in SDL and OpenGL
modes (with GL vblank waiting enabled). Pig (and the smooth scrolling
example) run much smoother, but when paying attention, I still notice minor
jerks (like single frame skips perhaps) every few seconds.

Now perhaps it’s just my system setup, but other games seem to run fine,
including my own, which as far as I can tell seems to run absolutely
smoothly, with OpenGL, but using the same framerate for the game logic as I
get with GL flips, i.e. 60Hz, and using simple linear scaling for the game
logic. For the current game (a simple vertical scrolling 2D asteroid shooter)
that’s not so much of a problem, since it seems to run fine on different
systems and doesn’t have complex maths or anything, but an older (and as of
yet unfinished) 3D racing game had serious problems with collision detection
and our acceleration function (again, simply scaled by the GL framerate
delay), which might be solved by converting to a fixed rate logic.

Any additional insights or tips would be helpful. :slight_smile:

Thx,
Marian.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

thanks man, these are awesome!

take care …On Friday 11 March 2005 21:19, Koshmaar wrote:

I think you should check out this link… and what’s hiding behind it
(especially Fix your timestep! page): ttp://www.gaffer.org:8080/articles/

HTH :slight_smile:

Koshmaar


Jonas Huckestein

Pub. PGP Key: http://pgp.upb.de:11371/pks/lookup?op=get&search=0xD2BAE645

"There was once a cross-eyed teacher who couldn’t control his pupils."
Another one: “I was wondering why the baseball kept getting bigger. Then it
hit me.” and “A bicycle can’t stand on its own. It’s two-tired.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050311/c46b694f/attachment.pgp

Let’s say we have 100 Hz game logic, and 60 Hz gfx. Then there are
100/60 ~= 1.67 logic frames per graphic update. Then somethimes there
will be two logic updates between two graphic frames, and sometimes
one.

Ok. I thought since it seems to be an often-used technique, interpolation
would reduce the effect so much that it isn’t noticeable (unfortunately, my
own eyes are quite trained in recognising this, since I’ve been trying to get
another computer to smoothly play DVDs on projector for months…)
Yes linear (or higher) interpolation will reduce the problem – don’t
know if beyond recognition though – at least not in non-constant
velocity motion. For linear moves it will remove the problem
altogether of course.

Then again, increasing the logic frame rate to 1000 Hz will look much
smoother, but now we might start considering the computational amount
needed to take the physics steps that many times per “game time step”

I haven’t yet looked at the interpolation details, but isn’t the whole point
of interpolation not having to use too high logic rates? 1000 Hz sounds
awfully high for a more complex game (and I guess it would be difficult to
time as well, with SDL_Delay having “only” 1ms resolution and a draw routine
that will take longer than 1ms).
Yes I agree 1000Hz seems a lot but then again it might be worth the
engineering complexity reduction compared to having “floating deltas”.

It does not matter if the graphics drawing takes more than 1 ms – the
human perception system has a latency of 10 ms from “event to brain
understanding” IIRC anyway – and to 250 ms when it comes to motor
reaction. The important part is keeping the “game/logic time” in pace
with the “real/computer time”.

/OlofOn Fri, 11 Mar 2005 21:11:04 +0100, Marian Schedenig <m.sched at gmx.at> wrote:

On Friday 11 March 2005 19:59, Olof Bjarnason wrote:

Marian.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Well of course fixed frame rate might seem jerky to the trained eye,
compared to “floating deltas”, if you look at a ball or something
moving at a constant speed over the screen or the prime example,
scrolling text, since every now and then there is one more or one less
logic step taken between to consequtive graphics frames:

Let’s say we have 100 Hz game logic, and 60 Hz gfx. Then there are
100/60 ~= 1.67 logic frames per graphic update. Then somethimes there
will be two logic updates between two graphic frames, and sometimes
one. Now when I come to think of it like this I’m not so sure I would
use dt = 10 ms (100 Hz) fixed logic frame rate since this WILL look
jerky :slight_smile:

Then again, increasing the logic frame rate to 1000 Hz will look much
smoother, but now we might start considering the computational amount
needed to take the physics steps that many times per “game time step”
… hmm. With a simple game physic/logic or very few objects, like in
the pong game discussed earlier today, that might be feasible, but I’m
not so sure in a many-many object game.

I’ve done it both ways, relative deltas based on the real elapsed time
and fixed deltas with as many steps as you need between frames. The math
is a little harder with relative deltas, but the computational cost is
the same for each frame and it is approximately equal to the cost of
computing the update for a fixed logic frame. So, if you are doing 1.67
(100 Hz) or 16.67 (1000 Hz) or what ever number of fixed increment
updates you are spending roughly 1.67 or 16.67 times as much computing
power between visible frames as the relative deltas technique does for
the same frame. In other words, you are potentially wasting a lot of CPU
cycles that you could be spending on game play.
Yup, it’s a time waste, but an engineering effort gain. Have I told
you I’m lazy :wink:

Another interesting thing, at lest to me, is that the fixed delta scheme
is basically using an iterative technique to approximate the same result
that the floating deltas produces. But, the floating deltas technique
gets the exact (within floating point accuracy) result while the fixed
delta technique gets only an approximation. Sort of like the difference
between evaluating an integral over a range by solving the integral and
evaluating it versus using an iterative numeric method to get the number
you want.

Yes, but numerically the methods both use a technique called Euler
forward, which is not-so-good when it comes to “exactness” (for
example the acceleration is assumed constant for the delta-time step,
which is not correct if you have a “local” gravitational field near
the object in motion). The difference is that doing 16-17 steps
instead of one as you are proposing, means a lot more error
propagation. But, if you have constant acceleration both methods are
equally accurate – and this is generally the case in a simple game
where you model gravitation as a constant added to the velocity-vector
each time step. If you want physically more accurate results in a
non-constant acceleration simulation, try Euler backward for example.
This method has higher computational cost as you might have guessed.

/OlofOn Fri, 11 Mar 2005 15:39:32 -0600, Bob Pendleton wrote:

On Fri, 2005-03-11 at 19:59 +0100, Olof Bjarnason wrote:

            Bob Pendleton

Interesting discussion!

/Olof

On Fri, 11 Mar 2005 19:12:08 +0100, Marian Schedenig <m.sched at gmx.at> wrote:

On Friday 11 March 2005 12:55, David Olofson wrote:

Have a look at my Fixed Rate Pig example, which demonstrates “ultra
smooth” animation while using a very low, fixed logic frame rate:
http://olofson.net/examples.html

(Or look at Kobo Deluxe, which uses the same technique - though I
suspect you won’t find that code as friendly to study. :wink:

Everytime fixed rate logic gets mentioned on this list (i.e., every few
days ;), I get more interested.

The only problem is, I tried both Fixed Rate Pig and Kobo Deluxe, and they do
NOT run entirely smoothly on my system (Dell Inspiron 8600 Laptop, Pentium M
1.6 GHz), 512 MB RAM, 64 MB GeForce FX Go5200 running at 60Hz, Debian Sid,
KDE using the official Nvidia drivers). The effect is most noticeable on
Kobo, which gives an obvious jerk every few seconds, both in SDL and OpenGL
modes (with GL vblank waiting enabled). Pig (and the smooth scrolling
example) run much smoother, but when paying attention, I still notice minor
jerks (like single frame skips perhaps) every few seconds.

Now perhaps it’s just my system setup, but other games seem to run fine,
including my own, which as far as I can tell seems to run absolutely
smoothly, with OpenGL, but using the same framerate for the game logic as I
get with GL flips, i.e. 60Hz, and using simple linear scaling for the game
logic. For the current game (a simple vertical scrolling 2D asteroid shooter)
that’s not so much of a problem, since it seems to run fine on different
systems and doesn’t have complex maths or anything, but an older (and as of
yet unfinished) 3D racing game had serious problems with collision detection
and our acceleration function (again, simply scaled by the GL framerate
delay), which might be solved by converting to a fixed rate logic.

Any additional insights or tips would be helpful. :slight_smile:

Thx,
Marian.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Yes linear (or higher) interpolation will reduce the problem – don’t
know if beyond recognition though – at least not in non-constant
velocity motion. For linear moves it will remove the problem
altogether of course.

And that’s exactly what bothers me. Fixed Rate Pig and the Smooth Scroll
Example apparently do use interpolation, and I still notice very slight
"hiccups" in regular intervals.

It does not matter if the graphics drawing takes more than 1 ms – the
human perception system has a latency of 10 ms from “event to brain
understanding” IIRC anyway – and to 250 ms when it comes to motor
reaction. The important part is keeping the “game/logic time” in pace
with the “real/computer time”.

I was mostly referring to the problem of having the same piece of code run
1000 times a second with an SDL_Delay once in each loop which needs at least
1ms and a drawing routine every few logic frames which takes more than 1ms
(assuming they are in the same thread).

Marian.On Friday 11 March 2005 22:47, Olof Bjarnason wrote:


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.

Yes linear (or higher) interpolation will reduce the problem – don’t
know if beyond recognition though – at least not in non-constant
velocity motion. For linear moves it will remove the problem
altogether of course.

And that’s exactly what bothers me. Fixed Rate Pig and the Smooth Scroll
Example apparently do use interpolation, and I still notice very slight
"hiccups" in regular intervals.

It does not matter if the graphics drawing takes more than 1 ms – the
human perception system has a latency of 10 ms from “event to brain
understanding” IIRC anyway – and to 250 ms when it comes to motor
reaction. The important part is keeping the “game/logic time” in pace
with the “real/computer time”.

I was mostly referring to the problem of having the same piece of code run
1000 times a second with an SDL_Delay once in each loop which needs at least
1ms and a drawing routine every few logic frames which takes more than 1ms
(assuming they are in the same thread).
OK, but why would you put delay(1) between each logic update? You want
the logic update(s) to execute as fast as possible. If you want to
give the OS some time to breathe, put one delay after the graphics
update…

/OlofOn Sat, 12 Mar 2005 00:47:39 +0100, Marian Schedenig <m.sched at gmx.at> wrote:

On Friday 11 March 2005 22:47, Olof Bjarnason wrote:

Marian.


Hofstadter’s law: “It always takes longer than you think,
even when you take account of Hofstadter’s law”.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[…]

The only problem is, I tried both Fixed Rate Pig and Kobo Deluxe,
and they do NOT run entirely smoothly on my system

They aren’t, and cannot (realistically) be on any hardware.

The reason is that the rendering isn’t sub-pixel accurate. You can
interpolate all you want, but as long as you truncate or round
positions to integer pixels, there’s no way to get perfectly smooth
animation, except in the special case that speeds happen to be exact
integer numbers of pixels per refresh.

The effect is most noticeable on Kobo, which gives an obvious jerk
every few seconds, both in SDL and OpenGL modes (with GL vblank
waiting enabled).

Sounds like your refresh rate is very close to a multiple of the
scrolling speed (3 pixels per 30 ms in 320x240). That’ll result in
very smooth scrolling - except that if the refresh rate doesn’t
exactly math the logic scrolling speed in integer pixels/frame,
there will be a step that’s one pixel bigger or smaller than normal
at regular intervals.

Pig

Pig isn’t scrolling, and objects move at different speeds, so the
effect might not be as obvious…

(and the smooth scrolling example) run much smoother, but when
paying attention, I still notice minor jerks (like single frame
skips perhaps) every few seconds.

Unless you’re just seeing the effect of some background process
stealing the CPU for too long every now and then (which invariably
happens without retrace sync, or when the driver implements retrace
sync by means of busy-waiting), that’s rather weird… (If you’re
talking about smoothscroll in OpenGL mode, that is. The SDL rendering
mode is not sub-pixel accurate, so that’s bound to have the same
issues as Pig and Kobo Deluxe.)

That said, due to the lack of a proper timing API for graphics
drivers, smoothscroll has to deal with scheduling latency jitter in
the timestamps that drive the “logic”. Later versions have a filter,
but unfortunately, while that improves the situation on the worst
systems, it seems to cause problems on systems that don’t really
need the filtering.

There is (currently) no way to reliably fix this without resorting to
driver hacks and/or real time kernels.

Well, there is one way that might work under certain conditions:

  • Simply assume that the refresh rate is exactly what
    the driver claims.
  • Assume that there flips are retrace sync’ed.
  • Assume that you’ll never drop a frame.

If you can rely on that, it’s as simple as dropping the SDL_GetTicks()
stuff and assuming that the delta between two frames is exactly one
display refresh period at all times. (It is, as long as the
reported refresh rate is correct and you don’t drop any frames.)

Now perhaps it’s just my system setup, but other games seem to run
fine, including my own, which as far as I can tell seems to run
absolutely smoothly, with OpenGL, but using the same framerate for
the game logic as I get with GL flips, i.e. 60Hz, and using simple
linear scaling for the game logic.

So does smoothscroll… (No fixed logic rate there, as all it does is
bounce around a map.)

Have you tried running it in GL mode with the filter disabled?
(-ntf option) If that doesn’t work, I must have screwed something up
in the maths. :slight_smile:

[…]

which might be solved by converting to a fixed rate logic.

BTW, if you’re worried about changing acceleration causing trouble,
there’s always quadratic and cubic interpolation. However, since
those require 3 and 4 “old frames” respectively, you may have to
increase the logic frame rate to maintain an acceptable input->output
latency. (You might have noticed that Kobo Deluxe feels a bit lagged
when playing at high frame rates. That’s because the logic frame rate
is only 33 Hz…)

Either way, I suspect that going beyond linear interpolation is
overkill, especially with “sane” logic frame rates.

Note that Pig uses a logic frame rate of 20 Hz. I’ve tried much lower
frame rates than that, but then the response times and input
quantization would just be too obvious. :slight_smile:

However, seriously; if you’re actually seeing any of the linear
segments that the interpolation generates between logic points, I
think I must have done something wrong in the maths, because I don’t
think it’s realistically possible under normal conditions -
especially not without sub-pixel accurate rendering.

Implementing sub-pixel accurate OpenGL rendering in Pig might be
interesting…

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Friday 11 March 2005 19.12, Marian Schedenig wrote: