SDL Event time information?
Hi,
With 3 friends from my Uni we're trying to write an FPS in OpenGL. First we decided to use SDL for input, as the OS independence was desired. I was the one to implement the InputSystem.
In FPS we need not only a chronology of input events, but also a precise information of relative time between the event had occurred and moment we picked it from the queue. Does SDL provide such information? I don't see the field in "SDL_Event" union.
Furthermore, if SDL does not, do you know any other OSI libraries for OpenGL that support precise input?
Regards and sorry for my English,
akuda
Quote:Original post by akuda
In FPS we need not only a chronology of input events, but also a precise information of relative time between the event had occurred and moment we picked it from the queue.
Why? if there is noticeable lag between a key press and the moment you process the event, then either you're doing it wrong™ or its time to look for bottlenecks in your code.
If you need current input state (as in what is the state of the mouse and keyboard NOW), use SDL_GetKeyState, SDL_GetRelativeMouseState and SDL_GetMouseState instead of the event queue.
I don't know if there is any way to do that or not, but if there isn't then I would make the input system operate updated at a rate faster than, say, the rendering and perhaps the closest equivalent to your 'physics' update rate. Say, once every millisecond. So every millisecond you get all input events that have occured since the last millisecond and just mark those as occuring at the same moment in time. In the real world this might be what the player enters
time input_event0.0005 CTRL0.0006 LEFT0.0011 CTRL0.0018 CTRL0.0041 RIGHT
And your game would treat this information astime input_event0.000 CTRL0.000 LEFT0.001 CTRL0.001 CTRL0.002 ...0.003 ...0.004 RIGHT
All that remains is to determine what you should do when there are multiple events that occur during the same slice. I would suggest interpolation. If there are 2 events the first occurs at the beginning of the slice and the second in the middle. If there are 3 events then beginning, 1/3rd, then 2/3rds. And so on.
@Kwizatz we need it to know if the player started/stopped to move within a moment of graphics slowdown. this *will* happen.
I just got the idea of setting up another thread constantly waiting on SDL_WaitEvent(), and putting the events into a buffer enriched with the delta-time value. Then, once per frame, the main thread cleans the buffer (mutex protected).
How good would that be? Is there a remarkable difference between this approach, and what-directX-provides?
I just got the idea of setting up another thread constantly waiting on SDL_WaitEvent(), and putting the events into a buffer enriched with the delta-time value. Then, once per frame, the main thread cleans the buffer (mutex protected).
How good would that be? Is there a remarkable difference between this approach, and what-directX-provides?
Quote:
I just got the idea of setting up another thread constantly waiting on SDL_WaitEvent(), and putting the events into a buffer enriched with the delta-time value. Then, once per frame, the main thread cleans the buffer (mutex protected).
SDL_WaitEvent() calls SDL_PumpEvents(), which may only be called by the main thread (due to the restriction imposed by SDL_SetVideoMode()). It would take a bit of work to setup a second thread to do your graphics processing, because SDL 1.2.X doesn't expose functions to manipulate OpenGL contexts.
I think Kwizatz is correct, you probably don't need as much precision as you think.
Quote:
How good would that be? Is there a remarkable difference between this approach, and what-directX-provides?
My understanding is that unless you are using a joystick/joypad, the DirectInput routines are effectively deprecated over standard Win32 input messages. A quick google appears to suggest that Win32 key press events do not have any timing information attached to them.
Quote:Original post by akuda
@Kwizatz we need it to know if the player started/stopped to move within a moment of graphics slowdown. this *will* happen.
Sounds like what you want is frame rate independent movement, it has little to do with input though, instead you sample time at the start of your game loop and check it with the last sampled value, elapsed time would be the difference between those two, you move your game pieces according to that.
Quote:Original post by akuda
How good would that be? Is there a remarkable difference between this approach, and what-directX-provides?
I don't think DirectInput provides this information either, again, if this is an issue for you right now, you should look for what exactly is causing the slowdown rather than work around it.
@rip-off
thanks for the info, you've just changed my plan saving me another stuck
@Kwizatz
yes, it does, if you use a buffered input. check the quake3 code, it's GPL nowadays.
furthermore, I'm not working around anything yet, as rendering pipeline does not exist, it's being written by other part of the team.
The truth is, that I received such problem statement, pointing that it is possible in DX, and we would like it to be possible in Linux. It's not my deviation, it's part of my job description.
And what about SFML? Can I create waiting input-thread there, or (as in SDL) there is some kind of implication stopping me from doing that?
thanks for the info, you've just changed my plan saving me another stuck
@Kwizatz
yes, it does, if you use a buffered input. check the quake3 code, it's GPL nowadays.
furthermore, I'm not working around anything yet, as rendering pipeline does not exist, it's being written by other part of the team.
The truth is, that I received such problem statement, pointing that it is possible in DX, and we would like it to be possible in Linux. It's not my deviation, it's part of my job description.
And what about SFML? Can I create waiting input-thread there, or (as in SDL) there is some kind of implication stopping me from doing that?
Quote:Original post by akuda
yes, it does, if you use a buffered input. check the quake3 code, it's GPL nowadays.
Seems it does, I am aware of the GPL status of the quake3 code and have studied it from time to time, thank you.
Quote:Original post by akuda
furthermore, I'm not working around anything yet, as rendering pipeline does not exist, it's being written by other part of the team.
The truth is, that I received such problem statement, pointing that it is possible in DX, and we would like it to be possible in Linux. It's not my deviation, it's part of my job description.
So, you're working on solving a problem you don't yet have but you believe will come to pass based on hearsay? YAGNI comes to mind.
Anyway, best of luck in your project.
@Kwizatz
thank you, you were very helpful. all you told (except that I sound like an ass, which is good to know) is that the quakes InputSystem does what I want, but (as you tried to prove in previous posts) I still wouldn't need it. Even though as I mentioned previously I'm asked to provide it, and it's not entirely mine decision.
The project leader might need it to just printf the statistics at the end. But instead of criticising him for it and trying to prove him wrong, I'm doing my job. Is that being an ass?
thank you, you were very helpful. all you told (except that I sound like an ass, which is good to know) is that the quakes InputSystem does what I want, but (as you tried to prove in previous posts) I still wouldn't need it. Even though as I mentioned previously I'm asked to provide it, and it's not entirely mine decision.
The project leader might need it to just printf the statistics at the end. But instead of criticising him for it and trying to prove him wrong, I'm doing my job. Is that being an ass?
Quote:Original post by akuda
@Kwizatz
thank you, you were very helpful. all you told (except that I sound like an ass, which is good to know) is that the quakes InputSystem does what I want, but (as you tried to prove in previous posts) I still wouldn't need it. Even though as I mentioned previously I'm asked to provide it, and it's not entirely mine decision.
The project leader might need it to just printf the statistics at the end. But instead of criticising him for it and trying to prove him wrong, I'm doing my job. Is that being an ass?
I meant the "go look at the quake code" bit. Sorry about that, edited the post, I blame it partially on the language barrier.
Anyway, I think you can get away with just using the time the event is processed, and just make sure to process all pending events each frame rather than one per frame, and of course pump events.
Again, best of luck.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement