I want to know if you prefer to get your
Input (Mouse/Keyboard/Joystick) in a separated
thread instead of putting a “UpdateInput” function
in your mainLoop ?
I’m thinking that it’s better in the mainLoop tick.
My co-worker wanna a thread.
With a thread we’ll need somes CriticalsSections…
We can have somes thread troubles…
But Input will be simple to manage…
We can scan more often or less often if we wanna to…
what did you think of that guys ? I’m right or my
co-worker is right ?? EhE
I want to know if you prefer to get your
Input (Mouse/Keyboard/Joystick) in a separated
thread instead of putting a “UpdateInput” function
in your mainLoop ?
Actually there are target (for instance my AmigaOS port ) that needs
that the event handling functions (waiting events practically) are
performed in the same thread that opened the window, I don’t know it this
is an official SDL directive but I seem to remember that somewhere I’ve
written that handling events in the thread that opened window is at least a
suggested behaviour, can someone confirm?
I think SDL_PumpEvents is the only function that have this
restriction,
"Note: You can only call this function in the thread that set the video
mode."
But then again, SDL_PollEvent and SDL_WaitEvent calls
SDL_PumpEvent, so it seems like, yes you have to have the
events handling in the same thread as the one that created the window.
Maybe someone with more knowledge can say if that is the case…
/Sammy> ----- Original Message -----
From: gabrielegreco@tin.it (Gabriele Greco)
To:
Sent: Friday, January 11, 2002 10:24 AM
Subject: Re: [SDL] Hello! Threads for Inputs…
At 13.47 10/01/02 -0500, you wrote:
I want to know if you prefer to get your
Input (Mouse/Keyboard/Joystick) in a separated
thread instead of putting a “UpdateInput” function
in your mainLoop ?
Actually there are target (for instance my AmigaOS port ) that needs
that the event handling functions (waiting events practically) are
performed in the same thread that opened the window, I don’t know it this
is an official SDL directive but I seem to remember that somewhere I’ve
written that handling events in the thread that opened window is at least
a
suggested behaviour, can someone confirm?
I could lie to you about that but I don’t see much point
I have done a multithreaded game with SDL, where I had
event handling in the main thread and the graphics handling
in another thread. It worked fine in both BeOS and Windows.
“works fine here” != compliant with API restrictions
There are a lot of stupid things you can do and get away with if you
are “lucky”. That does not make it right, or guarantee future luck
I could lie to you about that but I don’t see much point
I have done a multithreaded game with SDL, where I had
event handling in the main thread and the graphics handling
in another thread. It worked fine in both BeOS and Windows.
“works fine here” != compliant with API restrictions
There are a lot of stupid things you can do and get away with if you
are “lucky”. That does not make it right, or guarantee future luck
I could lie to you about that but I don’t see much point
I were just hoping that you were wrong ;-). Because it seems a
little limited that you in princip i stuck in the mainthread
when it comes to SDL calls.
I have done a multithreaded game with SDL, where I had
event handling in the main thread and the graphics handling
in another thread. It worked fine in both BeOS and Windows.
“works fine here” != compliant with API restrictions
Well it would be nice if this could mentioned in the documention
(if it not already does). Because there are people like me, that are
to lazy to read the source.
I think SDL_PumpEvents is the only function that have this
restriction,
“Note: You can only call this function in the thread that set the video
mode.”
Most of SDL has this limitation. The parts that don’t SHOULD, so that your
programs will work on MacOS Classic. Threads are evil anyhow. Avoid them
when you can.
So SDL_xx calls := in Main Thread ONLY.
.
.
.
and threads are evil !! Heh
Thx boys! SeeYa!
Ryan C. Gordon wrote:>>I think SDL_PumpEvents is the only function that have this
restriction,
“Note: You can only call this function in the thread that set the video
mode.”
Most of SDL has this limitation. The parts that don’t SHOULD, so that your
programs will work on MacOS Classic. Threads are evil anyhow. Avoid them
when you can.
I think SDL_PumpEvents is the only function that have this
restriction,
no. the only SDL calls that may be called from a thread other than the
main thread are
SDL_PushEvent
SDL_GetTicks
SDL_PeepEvents() may also be called from another thread besides the main one.
Some of the other subsystems besides video have functions that may be called
from other threads, but you shouldn’t unless you really know what you’re doing
and how SDL works internally.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I think SDL_PumpEvents is the only function that have this
restriction,
“Note: You can only call this function in the thread that set the video
mode.”
Most of SDL has this limitation. The parts that don’t SHOULD, so that your
programs will work on MacOS Classic. Threads are evil anyhow. Avoid them
when you can.
No, threads are not evil and if you aren’t interested in having your
code run
a MacOS then you shouldn’t be limited by the restrictions of MacOS. The
fact
that SDL is a cross platform environment does not imply that all code
written
using it is intended to run on more than one platform.
An alternative to having a wait event call in a thread is to have the
thread
wait on a condition variable or other mutex and having the main loop,
that
contains the wait event call, wake up the thread when events it wants
are
available. This way the thread can execute in parallel with the wait
loop. Or,
more cleanly, the result of a key press in the wait loop can start a
thread
to processs the key.
This approach still might not solve your problem because it looks like
the thread
can make many SDL calls. But, it the thread needs to do things that
don’t involve
SDL then this approach will solve the problem.
I think the best way is to setup a callback function(through the timer) so
you can get the events off the queue in a controlled matter(say 30 times a
second). This way your program is endlessly looping eating all your cpu and
also you are in more control and knowing exactly what your program is doing.
-Jordan Wilberding> On Thursday 10 January 2002 12:47, you wrote:
I want to know if you prefer to get your
Input (Mouse/Keyboard/Joystick) in a separated
thread instead of putting a “UpdateInput” function
in your mainLoop ?
I’m thinking that it’s better in the mainLoop tick.
My co-worker wanna a thread.
With a thread we’ll need somes CriticalsSections…
We can have somes thread troubles…
But Input will be simple to manage…
We can scan more often or less often if we wanna to…
what did you think of that guys ? I’m right or my
co-worker is right ?? EhE
I think the best way is to setup a callback function(through the timer) so
you can get the events off the queue in a controlled matter(say 30 times a
second). This way your program is endlessly looping eating all your cpu and
also you are in more control and knowing exactly what your program is doing.
This isn’t much better; most SDL platforms run the timer in a separate
thread, so you still need to contend with race conditions and such, and
you can’t guarantee the precision of the timer anyhow.
What is so difficult about handling the event queue once per iteration on
the game’s main loop?
Getting mouse and keyboard events out of your gameloop is fine. But when you
signal events like redrawing the screen and such, you need a way to keep a
steady framerate going. Even though a timer might not be completely accurate
it is still closer then any other means you will get.On Sunday 13 January 2002 20:46, you wrote:
I think the best way is to setup a callback function(through the timer)
so you can get the events off the queue in a controlled matter(say 30
times a second). This way your program is endlessly looping eating all
your cpu and also you are in more control and knowing exactly what your
program is doing.
This isn’t much better; most SDL platforms run the timer in a separate
thread, so you still need to contend with race conditions and such, and
you can’t guarantee the precision of the timer anyhow.
What is so difficult about handling the event queue once per iteration on
the game’s main loop?
–
Jordan Wilberding <@Jordan_Wilberding> Diginux.net Sys Admin
I think the best way is to setup a callback function(through the timer) so
you can get the events off the queue in a controlled matter(say 30 times a
second). This way your program is endlessly looping eating all your cpu and
also you are in more control and knowing exactly what your program is doing.
This isn’t much better; most SDL platforms run the timer in a separate
thread, so you still need to contend with race conditions and such, and
you can’t guarantee the precision of the timer anyhow.
What is so difficult about handling the event queue once per iteration on
the game’s main loop?
I asked that just for info, I’m a newbie to SDL and
I like to know the opinions of experienced SDL programmer like you!!
Now, our BETA game can show a “map”, if I can say that (BETA 0.0.0.1
map) and all the handling of the event queue is done once per iteration
(You convince me to stick in the main thread to be able to port is
easyer after (Just to SDL call in the main thread…);)>
