I’m trying to implement SDL_Events in my game engine and running up against a brick wall. Everything I read on the subject gives two mutually exclusive recommendations:
- Managing SDL_Events has to be done from the application’s main thread.
- The most efficient way to manage SDL_Events is with the SDL_WaitEvent function.
This just won’t work, because rendering also has to be done from the main thread. I can’t have my event loop stalling the rendering because the user isn’t hitting any keys! What kind of sense does it make to only have SDL_Events run on the main thread anyway, seeing as how the only sensible way to handle input in a multithreaded app using DirectX/OpenGL routines is in a different thread from the one doing the rendering?
Frankly, I don’t see the logic to this. Is there any way around it?
Mason Wheeler
This also confused me at first, but I ended up using Bob’s Fast Events library which is faster (obviously) and does let you run your event loop in a different thread (as long as it’s the same thread which initialized SDL). Then in the main thread I just continuously render OpenGL.
http://www.gameprogrammer.com/fastevents/fastevents1.html
By the way, there is an SDL initialization flag SDL_INIT_EVENTTHREAD, but I think it’s only supported on Linux at the moment. Anyway, look into the Fast Events library and see if it will do what you need.
Cheers,
Chaz----- Original Message -----
From: Mason Wheeler
To: sdl at lists.libsdl.org
Sent: Monday, February 25, 2008 9:24 PM
Subject: [SDL] SDL_Event threading all backwards?
I’m trying to implement SDL_Events in my game engine and running up against a brick wall. Everything I read on the subject gives two mutually exclusive recommendations:
- Managing SDL_Events has to be done from the application’s main thread.
- The most efficient way to manage SDL_Events is with the SDL_WaitEvent function.
This just won’t work, because rendering also has to be done from the main thread. I can’t have my event loop stalling the rendering because the user isn’t hitting any keys! What kind of sense does it make to only have SDL_Events run on the main thread anyway, seeing as how the only sensible way to handle input in a multithreaded app using DirectX/OpenGL routines is in a different thread from the one doing the rendering?
Frankly, I don’t see the logic to this. Is there any way around it?
Mason Wheeler
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Hello !
- The most efficient way to manage SDL_Events is with the
SDL_WaitEvent function.
Most games use SDL_PollEvent to get their events :
SDL_Event event; /* Event structure */
.
.
.
/* Check for events /
while(SDL_PollEvent(&event)) { / Loop until there are no events left
on the queue /
switch(event.type) { / Process the appropiate event type /
case SDL_KEYDOWN: / Handle a KEYDOWN event /
printf(“Oh! Key press\n”);
break;
case SDL_MOUSEMOTION:
.
.
.
default: / Report an unhandled event */
printf(“I don’t know what this event is!\n”);
}
}
SDL_WaitEvent is usefull when your app only does something
after an event, but most game loops should also run when
the user has not pressed a key or moved the mouse.
CU
IV {
MARGIN:0px;}
This also confused me at first, but I ended up
using Bob’s Fast Events library which is faster (obviously) and does let
you
run your event loop in a different thread (as long as it’s the same thread
which initialized SDL). Then in the main thread
I just continuously
render OpenGL.
Interesting. So then, to set this up, I’d have to run SDL_Init() from a thread that’s not the main thread of my app. That won’t cause trouble with the audio or the video routines? (Video routines have to be run from the main thread, afterall.) Obviously, this wouldn’t be an SDL_Thread it’s being called from. I’m writing this in Delphi for Win32, which has a built-in object-oriented thread model that my engine relies on pretty heavily. Will that cause any conflicts?
That shouldn’t be a problem because I’m not using SDL_Thread either. I’m using objc threads. And yes, you just call your video routines in the main thread. Of course, don’t forget to block the main thread after you detach your event thread until your event thread signals that SDL_Init and FE_Init have been been called so there’s no chance the video routines will be called before SDL is initialized from the other thread. I don’t used any SDL audio routines, but I imagine there wouldn’t be a problem.
Chaz----- Original Message -----
From: Mason Wheeler
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Monday, February 25, 2008 10:57 PM
Subject: Re: [SDL] SDL_Event threading all backwards?
This also confused me at first, but I ended up using Bob’s Fast Events library which is faster (obviously) and does let you
run your event loop in a different thread (as long as it’s the same thread which initialized SDL). Then in the main thread
I just continuously render OpenGL.
Interesting. So then, to set this up, I’d have to run SDL_Init() from a thread that’s not the main thread of my app. That won’t cause trouble with the audio or the video routines? (Video routines have to be run from the main thread, afterall.) Obviously, this wouldn’t be an SDL_Thread it’s being called from. I’m writing this in Delphi for Win32, which has a built-in object-oriented thread model that my engine relies on pretty heavily. Will that cause any conflicts?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
IV {
MARGIN:0px;}
That shouldn’t be a problem because I’m not
using SDL_Thread either. I’m using objc threads. And yes, you just
call
your video routines in the main thread. Of course, don’t forget
to block the main thread after you detach your event
thread until your event
thread signals that SDL_Init and FE_Init have been been called so there’s no
chance the video
routines will be called before SDL is initialized from the
other thread.
That won’t be a problem. Creating the event thread is the third line of code in my application; there are well over a thousand lines of initialization that run, including a fair amount of reading from the HD, before anything even begins to get drawn to the screen. 
shrug I guess this means I should try and translate FastEvents into Delphi and send it to the JEDI_SDL people. Thanks for your help!