Hello,
At my work, I’m currently developing in Swing. I was wondering if it was possible
to treat events in a loop situated in a separate thread, and post gfx updates
in the main thread, just like Swing’s EDT mechanism.
Thanks,
Julien CLEMENT
@Julien_Clement1
To a certain extent, yes. SDL’s event queue is thread safe, you can
push from any thread and you can pull from any thread. However, input
events are only collected by calls to SDL_PumpEvents(), which must be
called by the same thread that called SDL_SetVideoMode(). This thread
must be the main() thread, so you end up with the restriction that
SDL_PumpEvents() can only be called from the main thread. Also, the
two popular ways of getting events, SDL_PollEvent and SDL_WaitEvent(),
both call SDL_PumpEvents() internally, so these can only be called
from the main thread. You’d need to use SDL_PeekEvents() to do the
processing in a separate thread.
So it is possible, but not necessarily easy or recommended. This is
leaving aside additional complexity caused by managing access to
non-event data in your program.On 11 June 2011 09:49, Julien CLEMENT wrote:
Hello,
At my work, I’m currently developing in Swing. I was wondering if it was possible
to treat events in a loop situated in a separate thread, and post gfx updates
in the main thread, just like Swing’s EDT mechanism.Thanks,
Julien CLEMENT
clementj2005 at yahoo.fr
Julien CLEMENT wrote:
Hello,
At my work, I’m currently developing in Swing. I was wondering if it was possible
to treat events in a loop situated in a separate thread, and post gfx updates
in the main thread, just like Swing’s EDT mechanism.Thanks,
Julien CLEMENT
clementj2005 at yahoo.fr
As was previously stated, yes it is possible.
I don’t think there’s much point in it. It is very common to perform event processing in the main thread, even in many commercial games. It’s how things have been done for years; and if it worked fine for PC games in the 1990s; you can rest assured that it will work fine for your game on any recent hardware.
The only case where multi-threading input processing grants anything major is if your game logic (AI, physics, etc) lies in another thread (which is good design, especially nowadays); but even then it’s just as simple to pass a command with information into a thread-safe queue, and IMHO that’s better software design as well.------------------------
EM3 Nathaniel Fries, U.S. Navy
At my work, I’m currently developing in Swing. I was wondering if it was possible
to treat events in a loop situated in a separate thread, and post gfx updates
in the main thread, just like Swing’s EDT mechanism.
It happens to work on some platforms, but you shouldn’t do this.
Once a frame in your main loop, you can process events (and if they take
a long time to process, you can always put them in your own queue for
processing in a separate thread); this is very fast.
But you shouldn’t trust the underlying OS to handle this properly if
you’re drawing and reading events from it at the same time, or not at
the same time but from separate threads.
Don’t be fooled into thinking this “works,” even if it happens to work
for you.
–ryan.