Hi,
I wonder if it’s possible to use separate threads for blitting on strictly disjoint areas of the screen surface, by providing a simple synchronization mechanism so that the Update() process triggers when all the threads have finished their job.My problem is that I have a game with a fake LCD display at the bottom of the screen, displaying messages during the game with text scrolling effects (like in pinballs), and it’d be more practical to run the LCD program manager in a separate thread than to call a function at each step of the game. I wonder if I’m clear.
I know some of you will say it’s highly not recommendable to blit in separate threads, though ;)But I want to be fixed on that point
Julien
I think there will be trouble, unless you bypass the SDL blitters, as
they’re not designed to be thread safe…
How about “caching” the updates (as high level drawing operations, as
a raw pixel buffer or whatever suits your needs) and pushing them to
the screen from within the main loop?
Of course, practically all displays currently in use update the whole
screen at a steady rate at all times. The only way to achieve
perfectly smooth animation on such devices is to have the display
system dictate the pace. As such, threading and the like is pretty
much irrelevant when it comes to the actual rendering, unless you’re
trying to squeeze the full power out of multiple CPUs, cores and/or
GPUs. But you already knew that! ;)On Friday 08 May 2009, julien CLEMENT wrote:
Hi,
I wonder if it’s possible to use separate threads for blitting on
strictly disjoint areas of the screen surface, by providing a simple
synchronization mechanism so that the Update() process triggers when
all the threads have finished their job.My problem is that I have a
game with a fake LCD display at the bottom of the screen, displaying
messages during the game with text scrolling effects (like in
pinballs), and it’d be more practical to run the LCD program manager
in a separate thread than to call a function at each step of the
game. I wonder if I’m clear.
I know some of you will say it’s highly not recommendable to blit in
separate threads, though ;)But I want to be fixed on that point
–
//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 --’
I think there will be trouble, unless you bypass the SDL blitters, as
they’re not designed to be thread safe…
Not only that, but on some platforms (like Windows, I believe?), the
underlying APIs do not like being called from multiple threads… You
pretty much have to keep most of your SDL calls in the main thread,
otherwise it doesn’t work so well.
But a scrolling marquee doesn’t sound like it would be very difficult
to do as a state machine… You (referring to Julien here) also don’t
need to call that function “at every step of the game”, but rather
just once per frame, say just before calling SDL_UpdateRects or
SDL_Flip.
Threads are either for CPU intensive work where you would like to take
advantage of a multi-core system (doing physics for the next frame,
say) or for working around APIs that have inconveniently blocking
calls. If you can avoid them, do it, because the perceived extra work
of making that function called at every frame is almost certainly
dwarfed by the extra work of debugging you’ll put on yourself. ;-)On Fri, May 8, 2009 at 4:33 AM, David Olofson wrote: