Stuck with multiplayer and some segfaults

SDL Development
21

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:

That doesn’t matter if you’re interpolating. (As Kobo Deluxe and Pig
are doing.) You will get linear “segments” instead of smooth
curves, but after trying the Kobo Deluxe engine with logic frame
rates between 5 and 50 Hz, I dare say there’s no way to tell the
difference with sensible logic frame rates. (Say, above 20 Hz, if
even that.) The difference between the exact positions and the
piecewise linearly interpolated ones is in the order of fractional
pixels.

Then again, increasing the logic frame rate to 1000 Hz will look
much smoother,

Yes, but it’s a rather inefficient way of dealing with the problem.
You need insane logic frame rates to get anywhere near the accuracy
of simple, fast 24:8 fixed point interpolation with a logic frame
rate lower than the rendering frame rate. And if you’re going to do
sub-pixel accurate rendering (with OpenGL), you’ll need that
accuracy…

//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.net — http://www.reologica.se —On Friday 11 March 2005 19.59, Olof Bjarnason wrote:

22

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

Fixed logic frame rates are rather popular, but in most games I’ve
seen so far, it’s implemented by running the logic in a separate
thread, by “modulating” the number of calls to the game logic per
rendered frame, or by locking the whole game to a fixed frame rate.
Combining it with interpolation seems to be rather unusual, for some
reason.

[…]

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?

Yes, and no. As long as the logic frame rate is higher than the
rendering frame rate, it’s “sort of” sufficient - but it doesn’t
result in anything like smooth animation. Without interpolation,
“higher” is useless; you need “many times higher,” to even get close.

With interpolation, OTOH, you get perfectly smooth animation with a 5
Hz logic frame rate. Right; it won’t be accurate, there’ll be lots of
lag, and fast curved motiouns will start to show signs of linear
segments - but it’s still smooth, even at that low rates.

So, if you use interpolation, the selection of logic frame rate is
mostly about latency and collision detection accuracy. (Of course,
the latter is mostly a non-issue if you calculate the exact time of
impact, rater than just test for intersection once per logic frame.)

//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.net — http://www.reologica.se —On Friday 11 March 2005 21.11, Marian Schedenig wrote:

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

23

[…]

Yes I agree 1000Hz seems a lot but then again it might be worth the
engineering complexity reduction compared to having “floating
deltas”.

I think the area that could really use some complexity reduction is
collision detection and response. However, there just doesn’t seem to
be any way around some serious complexity here, except in simple
cases (like shooters, where objects don’t really interact, but just
die when they touch), or if you can make sure that objects move so
short distances per frame that it’s suficient to just assume
collisions occur exactly at the frame where intersection is detected.

//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.net — http://www.reologica.se —On Friday 11 March 2005 22.47, Olof Bjarnason wrote:

24

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.

I don’t think that has anything to do with linear interpolation -
unless there’s somethig funny going on in there.

If you did see any side effects of the interpolation, it would be that
curved motions get visible linear segments, and that accelerations
look stepped, sort of like in some old console games, where objects
"accelerate" by going at 1 pixel/frame for a few frames, then 2
pixels/frame for a while etc.

However, even in Pig (which deliberately uses a very low logic frame
rate), these linear segments are only 3…5 display refreshes in
duraction… Since the coordinates are rounded to integer pixels, the
output would be the exact same regardless of logic frame rate
(including variable/delta based) most of the time.

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).

There is nothing like that going on in Pig or Kobo Deluxe, at least.
The game logic runs in exactly one “burst” just before each frame is
rendered.

(SDL_Delay() is not used at all normally, since all it does on my
systems is guarantee that there’s no way to render at the full
refresh rate…)

//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.net — http://www.reologica.se —On Saturday 12 March 2005 00.47, Marian Schedenig wrote:

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

25

Anyway, this doesn’t have all that much to do with SDL any more, so I
suggest we move over to Gameprogrammer:

http://gameprogrammer.com/mailinglist.html

//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.net — http://www.reologica.se —

26

I was assuming the logic rate should run at regular intervals to correctly
deal with input times. Some breathing time is necessary since the Linux
kernel seems to take control away for a rather long while when it detects a
program running at 100%, but as long as vertical blank syncing is enabled,
everything should work fine.

Marian.On Saturday 12 March 2005 09:38, Olof Bjarnason wrote:

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…

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

27

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.

Exactly what’s been bothering me with setting up that projector as well, I
just hoped it wouldn’t be noticeable with fixed rate logic and interpolation.

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

I’d say it’s as obvious (i.e. hardly obvious at all, but unfortunately I still
noticed it) in Pig as in smothscroll.

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…

OpenGL is using vblank syncing, and enabling that has lead to very smooth
animations in other programs (including my own), so I don’t think that should
be the problem.

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.)

Then perhaps it’s just more noticeable in your programs than in my own…I’ll
better try a demo scrolling a full-screen image myself to make sure.

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:

I see no difference between normal mode and -ntf. In both cases, it does run
very smooth, but (perhaps this is a better description of the effect I’m
seeing) at a slightly uneven speed. There are no real “jumps” or anything in
the animation, but it visibly doesn’t always run at exactly the same speed.

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.

Since I get the same effect with smoothscroll, I guess it isn’t related to
interpolation. I’ll do a full-screen scrolling test with my own routines
(which seem to be running smoothly to me, although as I said they use the
display frame rate for logic, scaling by floats) and report.

Marian.

PS: Reading your other message, I just subscribed to the Gameprogrammer list.On Saturday 12 March 2005 10:43, David Olofson wrote:

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

28

[…]

I see no difference between normal mode and -ntf.

…which means you have proper retrace sync and very accurate
scheduling. (Otherwise, running without the filter would inject
scheduling jitter into the scroll speed even when running at a steady
full frame rate.)

In both cases, it does run
very smooth, but (perhaps this is a better description of the effect
I’m seeing) at a slightly uneven speed. There are no real “jumps” or
anything in the animation, but it visibly doesn’t always run at
exactly the same speed.

Hmm… The plot thickens.

It would be interesting to see a log of delta times and scroll offsets
over a few periods of these variations. Unless smoothscroll is
actually dropping frames (which would be very obvious), it has to
be either the delta times or the calculations, I think…

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.

Since I get the same effect with smoothscroll, I guess it isn’t
related to interpolation.

Well, if it’s just slight variations in speed (as opposed to periodic
jerking), it’s probably the time base.

I’ll do a full-screen scrolling test with my own routines
(which seem to be running smoothly to me, although as I said they
use the display frame rate for logic, scaling by floats)

…as does smoothscroll. (Only Pig and Kobo use fixed rate logic.)

and report.

That would be interesting. I’d rather like to know if I’m doing
something wrong… Pig and smoothscroll are supposed to be examples
of how to use SDL properly, so they should of course be correct, as
far as is realistically possible. :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.net — http://www.reologica.se —On Saturday 12 March 2005 15.21, Marian Schedenig wrote:

29

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…

I was assuming the logic rate should run at regular intervals to
correctly deal with input times.

Good thinking.

It can’t work that way if it’s done in the rendering thread, unless
rendering can be done quickly enough not to interfere with this
timing - but just grabbing and timestamping the input events in
another thread should work. (Provided the OS can actually provide
better timing that way, that is.)

Some breathing time is necessary since the Linux
kernel seems to take control away for a rather long while when it
detects a program running at 100%, but as long as vertical blank
syncing is enabled, everything should work fine.

Exactly.

//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.net — http://www.reologica.se —On Saturday 12 March 2005 15.05, Marian Schedenig wrote:

On Saturday 12 March 2005 09:38, Olof Bjarnason wrote: