[SDL] Blitting / event handling with multiple threads

[David Olofson]

On Tuesday 01 February 2005 21.05, Clemens Kirchgatterer wrote:
> Christian Morgner <christian.morgner at postamt.cs.uni-dortmund.de> 
wrote:
> 
> > Now the docs say that SDL_Flip() waits for vertical retrace, thus
> > delaying the execution of everything within the while() loop?
> 
> if, SDL_Flip() waits for the monitor refresh depends on many faktors
> (OS, driver, ...) if you really don't want to wait, why not use
> SDL_UpdateRect() instead? your game should run on maximum speed
> then. 

Yeah - and there will be tearing and excessive heat. :-)


Why not a decoupled fixed logic frame rate + interpolation?

 http://olofson.net/examples.html
 http://olofson.net/download/pig-1.0.tar.gz


Note that you can still run input in a separate thread, to get a fixed 
control latency rather than quantization at low rendering frame 
rates. You don't have to make a total mess of everything by running 
all of the game logic in the "input thread"... The only time it makes 
sense to do that is in networked games, where the "frame rate 
induced" control latency would add to the total when running the game 
logic in the rendering thread. Even then, it might actually be 
sufficient to just do input and networking in a separate thread, and 
keeping the local game logic in the rendering thread... The local 
display will have a certain minimum latency anyway, and it does't 
matter if you do the logic when reading input events or in the 
rendering loop; the input to visible feedback latency is the same 
regardless.


//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 ---