SFML community forums
Help => General => Topic started by: bmn on October 16, 2009, 04:46:22 pm
-
Hi,
I know the title sound weird, but allow me to expand it:
whoever red the code of quake3 surely noticed, that their directx based implementation of input system is system-buffered and, which is most important, provides with a captured event the information of "delta time" between the event has occurred (or has been recorded by DX) and the moment we red it from the buffer.
This "delta time" value is particularly valuable in FPS games, where an abstraction between input precision and frame rate is desired.
So far, I've been using SDL for cross-platform products, but now I received a job description that requires this delta-time value to be provided by an input system. By reading SFML "Event" class documentation, I've noticed, that SFML has no such feature built-in.
The team's idea was to start a different thread, waiting for input events, and capture them immediately, enrich with the "delta-time" value, and put in the mutex-protected buffer, so the main thread can read the buffer with the desired values.
In SDL, due to it's design, such approach would be unsuccessful, as the SDL_WaitEvent (which we wanted to loop in the input-thread) calls internal functions specific to main thread.
Has SFML the same restriction? Or can the desired result be achieved different way in SFML library?
Regards,
akuda
-
Has SFML the same restriction?
Yes, at least on Windows. This is because the OS requires that events are read in the same thread that created the window.
Or can the desired result be achieved different way in SFML library?
I don't know, but it looks like it's the only solution.
-
well actually it's no solution at all :)
are you planning to add this feature into future versions of your library?
-
So far, no. But why not!
-
Has SFML the same restriction?
Yes, at least on Windows. This is because the OS requires that events are read in the same thread that created the window.
Similar with Mac OS X. The event loop has to be handled from the main thread.
-
The event loop has to be handled from the main thread
The main thread, or the one that created the window?
-
The main thread, no matter in which thread the window was created (though I'm not even sure it's possible to create a window in a thread other than the main one).
-
In windows it's the thread that created the window, but one can theoretically have the opengl operations running in another thread (been experimenting with that a bit)
-
Yes it is possible. You just have to deactivate the window (SetActive(false)) before using it in another thread.
-
Yes it is possible. You just have to deactivate the window (SetActive(false)) before using it in another thread.
Yes, but I have been observing (non-deterministic) pauses and crashes when closing the window, even in very, very simple apps