Forget

Forget about my previous message.
Actually, the slow down was due to the following mistake (hope this will help
some of you) :

I was doing (pseudo code)

for ( ; game.running ; )
{

        if ( SDL_PollEvent(&evt) > 0 )
        {
   
            /* Treat the next event in the queue */

       }

        SDL_Delay(5);

}



Instead of:



for ( ; game.running ; )
{

        ticks = SDL_GetTicks();

        while ( SDL_PollEvent(&evt) > 0 )
        {
   
            /* Treat the next event in the queue */

       }

        while ( SDL_GetTicks() - ticks < 5 )
                ;
    
}

(“while” instead of “if”, and use of SDL_GetTicks instead of SDL_Delay)

I’m not sure about the explaination: The"if" doesn’t empty the
event loop but get the next available event.
Hence the queue may grow in size and slow down the game.

The “while” empties the event loop by treating all the events which occured
since the previous frame.

Then, last thing, it seems that SDL_GetTicks() is more precise because it
takes in account the time needed to perform one game step while SDL_Delay()
just delays in every case.

Thank you for your advice

Julien_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

Then, last thing, it seems that SDL_GetTicks() is more precise because it
takes in account the time needed to perform one game step while SDL_Delay()
just delays in every case.

It’s more precise because there’s no actual sleeping done. This also
means that your CPU will be pegged at 100%. You should replace the
"while ( SDL_GetTicks() - ticks < 5 )" with the following:

Uint32 now = SDL_GetTicks();
if (now < ticks + 5)
SDL_Delay(ticks + 5 - now);

Supposing that the game drawing is somewhere between that code and the
"ticks = SDL_GetTicks();", that will set a target frame rate of 200
fps (I’d personally replace the 5 with 10, making the target frame
rate 100 fps, it’s plenty and will actually manage to sleep once in a
while!). After getting the events and drawing, it will check how early
it is, and only if it’s ahead of time, sleep a little bit (just the
right amount). This might go past, of course, but that will be
smoothed out on the next frame, where it might be a tiny bit late, so
there wouldn’t be any sleeping.

If it’s running on a computer that is insufficiently fast, it will
never sleep, but that’s kind of okay, I suppose.

You could have an “else SDL_Delay(0);”, doing that seems to hint some
platforms’ OS scheduler that here would be a good time for letting
other processes go. If your game doesn’t aim for a target frame rate,
and really just wants to go as fast as possible, you could also do
just “SDL_Delay(0);”, and not bother with the whole SDL_GetTicks()
business.

Note that many OS schedulers reward processes that sleep (for example,
the “interactivity bonus” on Linux). In practice, that means that
SDL_Delay() becomes more accurate, because you get put closer to the
front of the run queue when the delay is over, so your process becomes
runnable more quickly (that’s why it’s called the “interactivity
bonus”).

If you write a backgammon game (or something like that) where there is
no animations while you wait for the next move, using SDL_WaitEvent()
is best. Ideally, SDL_WaitEvent() would take a (optional) timeout,
which would allow you to do animations while sleeping as much as
possible, but for now, we have to fake it with a loop of
SDL_PollEvent() (which is okay for now, since that’s what
SDL_WaitEvent does anyway! check out the source).On Wed, Jul 2, 2008 at 8:45 AM, julien CLEMENT wrote:


http://pphaneuf.livejournal.com/

Julien,

From what I can see of the psuedo-code, the biggest difference does not come from SDL_GetTicks() vs. SDL_Delay. It’s actually the “if” vs. “while” blocks. See, in the first example, you have an “if” statement, which, if true, will process the next event(and only one event!) and then sleep for 5ms. In other words, it will sleep 5ms after every event that is processed!! Talk about a slow-down!

In your second example, your “while” loop will actually process every pending event in the queue before reaching the ~5ms sleep. This is what keeps you from slowing down (and is a correct way of processing the queue).

However, as mentioned previously, you really should switch back to using SDL_Delay, so that your program doesn’t hog the CPU completely. The user’s system will still be responsive if they switch from your game to check email or whatever - preventing them from shutting your game off prematurely(and perhaps permanently!) just to take a small break from it.
-Dave----- Original Message -----
From: julien CLEMENT
To: SDL
Sent: Wednesday, July 02, 2008 7:45 AM
Subject: [SDL] Forget

Forget about my previous message.
Actually, the slow down was due to the following mistake (hope this will help
some of you) :

  I was doing (pseudo code)

  for ( ; game.running ; )
  {

        if ( SDL_PollEvent(&evt) > 0 )
        {
     
           /* Treat the next event in the queue */

        }

        SDL_Delay(5);

  }



  Instead of:

  

  for ( ; game.running ; )
  {

        ticks = SDL_GetTicks();

        while ( SDL_PollEvent(&evt) > 0 )
        {
     
           /* Treat the next event in the queue */

        }

        while ( SDL_GetTicks() - ticks < 5 )
              ;
      
  }

(“while” instead of “if”, and use of SDL_GetTicks instead of SDL_Delay)

I’m not sure about the explaination: The"if" doesn’t empty the
event loop but get the next available event.
Hence the queue may grow in size and slow down the game.

The “while” empties the event loop by treating all the events which occured
since the previous frame.

Then, last thing, it seems that SDL_GetTicks() is more precise because it
takes in account the time needed to perform one game step while SDL_Delay()
just delays in every case.

Thank you for your advice

Julien


Envoy? avec Yahoo! Mail.
Une boite mail plus intelligente.



SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Pierre Phaneuf escreveu:

It’s more precise because there’s no actual sleeping done.

A small note: SDL_GetTicks() is much faster on Win9x than on WinXP (and
probably all of the NT family). The program where I found it out was
doing a lot of other computations for some limited time (tested with
SDL_GetTicks()); the exact same binaries (program and SDL.dll) ran an
order of magnitude faster on Win98 than on XP when using SDL_GetTicks().

So although no sleeping is done, the OS might use the system call to put
the program at the end of the queue to run again.–
Daniel K. O.
“The only way to succeed is to build success yourself”