[SDL] SDL_PollEvent()

[Matthias Weigand]

Hi,

my loop looks like this:

while(!quit)
{
  uint32 t = SDL_GetTicks() + 20;

  handleAllTheThings();
  drawAllTheThings();
  SDL_GL_SwapBuffers();

  int32 timetowait = t - SDL_GetTicks();
  if (timetowait > 0)
    SDL_Delay(timetowait);
}

Didn't look for my exact code, but this is what it should be. This loop 
makes one iteration to last at least 20ms, resulting in 50fps. The 
downside is, that this code only works properly if a performance timer 
is present.

Matthias





David Olofson schrieb:
> On Thursday 09 November 2006 21:52, pixel fairy wrote:
> [...]
>   
>>> The problem with a delay in the render loop is that it often
>>> results 
>>> in less smooth animation on properly configured systems (it just
>>> interferes with the retrace sync), so you should probably make it
>>> optional, or possibly switch it on automatically when needed.
>>>       
>> i like this idea. whats a good way to detect if retrace sync is
>> disabled?
>>     
>
> Hairy business... Since there is no reliable or portable way of just 
> asking the driver, all you can do is analyze the timing and try to 
> make some sense of it. Unless you're on a hard real time OS, there 
> will likely be loads of timing jitter everywhere. Also, you'd 
> probably have to do the testing with very minimal rendering, just in 
> case hardware/resolution/scene complexity of the game is too much 
> for "full frame rate" as in "one rendered frame for each display 
> refersh".
>
> Basically, if you collect timestamps taken right after the 
> SDL_GL_SwapBuffers() call, modulo some jitter, you should see a 
> granularity corresponding to the display refresh rate. (Of course, 
> you'll have to vary the rendering load a bit during the test, to 
> avoid confusing your "unsynced" frame rate with the refresh rate 
> you're looking for.)
>
> If you're rendering one frame per refresh, then gradually increasing 
> the rendering load should have no effect, until rendering a frame 
> takes more than one refresh period, at which point the frame rate is 
> halved.
>
>
> Another thing you might want to analyze (simpler, perhaps) is the 
> execution times of the SDL_GL_SwapBuffers() call. (That is, compare 
> before/after timestamps.) If these are about the same all the time, 
> regardless of scene complexity (rendering load), you're not retrace 
> sync'ed.
>
> Note that the execution times may be anything from virtually zero for 
> a true hardware page flip (the proper way) without retrace sync, 
> through several milliseconds for a brute force back-to-front blit 
> copy (the way it's usually done in windowed mode on most platforms).
>
>
> Alternatively, if there's a reliable way of finding out how much CPU 
> time your application consumes, you can just check that. (Some 
> operating systems may have "funny" ways of measuring CPU load...) If 
> it's practically 100% at all times, you're most likely on a display 
> setup without retrace sync.
>
>
> Or, just throw in a manual "Frame Rate Throttling" option. :-) I did 
> this in Kobo Deluxe - although that was really intended for saving 
> battery on laptops. (Kinda' pointless running the CPU and GPU full on 
> to push 300+ fps when the TFT can't handle more than 60 fps or so, at 
> best.) It just has the side effect of also being useful when an 
> annoyed OS scheduler decides block the game for extended periods of 
> time, to allow background processes to run.
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> .-------  http://olofson.net - Games, SDL examples  -------.
> |        http://zeespace.net - 2.5D rendering engine       |
> |       http://audiality.org - Music/audio engine          |
> |     http://eel.olofson.net - Real time scripting         |
> '--  http://www.reologica.se - Rheology instrumentation  --'
>
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl
>
>
>