Message/Event Handling/Queuing in FPL

Finalspace  —  3 weeks ago [Edited 21 minutes later]
At the moment FPL have no way to let you handle the os events directly. It just queues it up internally so you can fetch it later, but this is wrong and needs to be fixed. So i am fixing that right now.

But this will result in a api change regarding fplWindowUpdate(), fpl*Event() and so on.
Also the impact of change will be very huge, because it affects all window and input handling.

I dont expect that to be done very soon so maybe it will be done by mid of october, but i cant promise :-(
Finalspace  —  2 weeks, 6 days ago [Edited 8 minutes later]
I finished the change of the event handling for win32 and removed the functions fplPushEvent() and fplUpdateGameControllers().
The good thing is fplPollEvent() and fplWindowUpdate() does not require any api change at all which is great.

The game controllers will still be detected in fplWindowUpdate() and create events for that (If not disabled) but OS events wont not be processed there anymore.

fplPollEvent() gets either the next event in the internal queue or the next event from the OS, but the internal queue will always have the higher priority.

The only downside of this change is that window based applications needs to process the events always, otherwise the window will get unresponsive, but i added a fplPollEvents() which just gets all the events from the OS - without needing the caller to handle it.
This is useful for games where you dont care about the events at all, because you get your input from polling only.
Log in to comment