SDL/OpenGL and smooth animation (again)

I have problem with smooth animation when using SDL and OpenGL. This problem
appears even with very simple animations. I described it few months ago here,
but now I will give you example.
I modified SDLgears application a little. As you can see in SDLgears code -
gears speed depends on CPU or gfx speed. How to make it independent? I’ve
modified idle() function with SDL_GetTicks() call.
Please test if this problem appears on your system, too:

  1. Download SDLgears from SDL homepage
    (http://www.libsdl.org/opengl/SDLgears-1.0.2.tar.gz)

  2. Apply following patch:

---------cut here---------

— SDLgears.c Mon Jul 24 22:52:59 2000
+++ SDLgears-jp.c Mon Apr 29 06:10:49 2002
@@ -44,6 +44,7 @@
#endif

static GLint T0 = 0;
+static GLint t,last_t = 0;
static GLint Frames = 0;

@@ -216,7 +217,8 @@

Frames++;
{

  • GLint t = SDL_GetTicks();
    
  • last_t=t;
    
  • t = SDL_GetTicks();
    if (t - T0 >= 5000) {
       GLfloat seconds = (t - T0) / 1000.0;
       GLfloat fps = Frames / seconds;
    

@@ -231,7 +233,7 @@
static void
idle(void)
{

  • angle += 2.0;
  • angle += (t-last_t)/50.0;
    }

/* new window size or exposure */

---------cut here---------

  1. Compile and run ./SDLgears
    On my system animation is very unsmooth. Gears “stutter”.

  2. Add:

    SDL_Delay(20);

    to idle() function.

  3. Compile and run ./SDLgears
    Animation is perfectly smooth now!

How can you explain that? I also tried adding SDL_Timer instead SDL_GetTicks(),
with exactly same result. Is it any other way to make gears speed same on every
system? By adding SDL_Delay() I lose a lot of CPU time!

You may say, that the problem is in “int” - there is small error every time, so
there is huge sum of errors. So I tried “angle=t/50.0” (without add) - nothing
changes.

My system is Linux-2.4 with XFree86-4
Hardware: K6-2 500, Voodoo3

I thought it is tdfx related, but few days ago I have seen similiar effect on
Radeon and Duron 1000.

Please answer, I really need to know what is happening there…

Today I bought Athlon XP 1800, and “stuttering” is much worse than before.
Without SDL_Delay(20.0), my engine (http://decopter.sf.net) is unplayable :frowning:
I was searching for any SDL/OpenGL game which sync physics with timer, but
failed. Do you know this kind of game?

Today I bought Athlon XP 1800, and “stuttering” is much worse than before.

I’m pretty sure this is caused by your process taking up all the CPU,
and the X server not able to pass the rendering commands on to the card.
However, I haven’t looked at the X server source code to verify this.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Hm… of course, my process easting whole CPU, but AFAIK every realtime game
does it to gain maximum fps. I tried to put physics calculations in separade
thread, but still SDL_Delay(20) was needed for main thread (after drawing). I
played a little with drivers, and it’s little better now, but my engine should
work without problems on every hardware…
Is there any open source SDL/OpenGL game which sync physics with timer? Any
car/air simulation? I think I should check Quakeforge…On Thu, May 02, 2002 at 07:01:53PM -0700, Sam Lantinga wrote:

I’m pretty sure this is caused by your process taking up all the CPU,
and the X server not able to pass the rendering commands on to the card.
However, I haven’t looked at the X server source code to verify this.

Check twilight instead, we’re pure SDL.

http://twilight.sf.net/

At last check QuakeForge was not.On Fri, May 03, 2002 at 07:01:02AM +0200, Jacek Pop?awski wrote:

On Thu, May 02, 2002 at 07:01:53PM -0700, Sam Lantinga wrote:

I’m pretty sure this is caused by your process taking up all the CPU,
and the X server not able to pass the rendering commands on to the card.
However, I haven’t looked at the X server source code to verify this.

Hm… of course, my process easting whole CPU, but AFAIK every realtime game
does it to gain maximum fps. I tried to put physics calculations in separade
thread, but still SDL_Delay(20) was needed for main thread (after drawing). I
played a little with drivers, and it’s little better now, but my engine should
work without problems on every hardware…
Is there any open source SDL/OpenGL game which sync physics with timer? Any
car/air simulation? I think I should check Quakeforge…

Jacek Pop?awski wrote:

Today I bought Athlon XP 1800, and “stuttering” is much worse than before.
Without SDL_Delay(20.0), my engine (http://decopter.sf.net) is unplayable :frowning:
I was searching for any SDL/OpenGL game which sync physics with timer, but
failed. Do you know this kind of game?

Rather than synching you physics to a timer, have you tried basing the
physics on the current time? It is very easy to get a "beat frequency"
effect that causes terrible stuttering when you lose synch between the
game physics and the rendering systems natural frame rate.

		Bob Pendleton> 

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


±-----------------------------------------+

  • Bob Pendleton, an experienced C/C++/Java +
  • UNIX/Linux programmer, researcher, and +
  • system architect, is seeking full time, +
  • consulting, or contract employment. +
  • Resume: http://www.jump.net/~bobp +
  • Email: @Bob_Pendleton +
    ±-----------------------------------------+

D?a Pi, 2002-05-03 at 07:01, Jacek Pop?awski nap?sal:> On Thu, May 02, 2002 at 07:01:53PM -0700, Sam Lantinga wrote:

I’m pretty sure this is caused by your process taking up all the CPU,
and the X server not able to pass the rendering commands on to the card.
However, I haven’t looked at the X server source code to verify this.

Hm… of course, my process easting whole CPU, but AFAIK every realtime game
does it to gain maximum fps. I tried to put physics calculations in separade
thread, but still SDL_Delay(20) was needed for main thread (after drawing). I
played a little with drivers, and it’s little better now, but my engine should
work without problems on every hardware…
Is there any open source SDL/OpenGL game which sync physics with timer? Any
car/air simulation? I think I should check Quakeforge…


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

I haven’t seen your game but the problem seems to be related to
SDL_Delay.
I doubt that you are taking all CPU power. Maybe I’m wrong but you seem
to be attempting to get fixed frame rate with SDL_Delay between frames.
The problem is that you aren’t guaranted to wait precisely the time you
pass to SDL_Delay. It’s upon to the sheduler to sleep your thread. If
you need to wait, you should use something like busy wait.

But there is a better approach - variable frame rate with interpolation
of movement. This has been discussed here later and as far as I remember
there was a tutorial on flipcode as well. You should check it.

-matej

I don’t understand. Please look at my patch for sdlgears. I calculated angle
from current time, and it didn’t work well.On Fri, May 03, 2002 at 10:49:42AM -0500, Bob Pendleton wrote:

Rather than synching you physics to a timer, have you tried basing the
physics on the current time? It is very easy to get a "beat frequency"
effect that causes terrible stuttering when you lose synch between the
game physics and the rendering systems natural frame rate.

I’m pretty sure this is caused by your process taking up all the CPU,
and the X server not able to pass the rendering commands on to the
card. However, I haven’t looked at the X server source code to verify
this.

Hm… of course, my process easting whole CPU, but AFAIK every
realtime game does it to gain maximum fps.

Yes - and besides, a proper driver would have the game block whenever the
"command buffer" is full.

I tried to put physics
calculations in separade thread, but still SDL_Delay(20) was needed for
main thread (after drawing). I played a little with drivers, and it’s
little better now, but my engine should work without problems on every
hardware…
Is there any open source SDL/OpenGL game which sync physics with timer?
Any car/air simulation? I think I should check Quakeforge…

Don’t all properly implemented games do that, one way or another…?

Anyway, last time I saw a problem like this (if I understand it
correctly) was when I had a broken G400 driver that wouldn’t block the
application at all, until the (huge!) command buffer was full. At that
time, it would render like 5 - 20 frames fast as h*ll, and then let the
game thread run again. The same thing happened with Q3A as well as my
code.

Solution:
glFlush();
SDL_GL_SwapBuffers();
glFinish();

This sucks, of course, but it was the only way to get that driver to do
anything useful in windowed mode.

BTW, the fact that this is not normally required seems to suggest that
all “working” drivers implicitly block the application as soon as there
is no new buffer available for rendering, rather than when the command
buffer is full. (Think about it, and you’ll realize why the latter cannot
work if the application uses anything but retrace sync/frame count for
timing - which is not possible with current APIs.)

//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 |-------------------------------------> http://olofson.net -'On Friday 03 May 2002 07:01, Jacek Pop?awski wrote:

On Thu, May 02, 2002 at 07:01:53PM -0700, Sam Lantinga wrote:

Jacek Pop?awski wrote:>On Thu, May 02, 2002 at 07:01:53PM -0700, Sam Lantinga wrote:

I’m pretty sure this is caused by your process taking up all the CPU,
and the X server not able to pass the rendering commands on to the card.
However, I haven’t looked at the X server source code to verify this.

Hm… of course, my process easting whole CPU, but AFAIK every realtime game
does it to gain maximum fps. I tried to put physics calculations in separade
thread, but still SDL_Delay(20) was needed for main thread (after drawing). I
played a little with drivers, and it’s little better now, but my engine should
work without problems on every hardware…
Is there any open source SDL/OpenGL game which sync physics with timer? Any
car/air simulation? I think I should check Quakeforge…


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

I may be coming quite late to this discussion cause I’m about 200 SDL
messages behind here…

But anyway, at this location:

http://modzer0.cs.uaf.edu/~skugg/roids/tars/

I have something that may do what you want (should run on Linux, Win32,
OSX), or at least be interesting. In particular, in the lastest source
there is a file main.cpp, lines 378-381 is where the “high-level” junk
is done. delay() and update() are in update.cpp, draw() is in draw.cpp.

The key is of course the timer… basically it works like this:

  1. Get an SDL time
  2. Draw my scene (openGL)
  3. Get SDL time and compare, store this time for next loop.
  4. Do that many physics calculations. Go back to 2.

This basically gets 1000 physics updates per second on any computer, and
then leaves what’s left for drawing. Would be possible to scale that
number of physics updates down, but you’d probably need to carry a
remainder, etc etc. (I use 1000 updates for semi-high-speed collision
checking.)

Hope thats useful.

                                        -ray skoog