SFML community forums

Help => Window => Topic started by: zenroth on January 31, 2013, 04:40:10 am

Title: Tactics for handling Input Injection and Real Time Polling
Post by: zenroth on January 31, 2013, 04:40:10 am
I'm starting to work with some GUI libs that need to consume the input events in order to work correctly, but then game code is using the real time system.

Just wondering if anyone has some well known approaches to handling this?

Ditching real time is obviously one solution, but might not always be ideal.
Title: Re: Tactics for handling Input Injection and Real Time Polling
Post by: eXpl0it3r on January 31, 2013, 04:44:37 am
I don't see a problem of mixing events and real time input, so I don't quite understand the problem here...

E.g. you just poll the events and pass it on to the GUI lib, while you're doing whatever you were doing with your game and the real time inputs. ;)

If you want to handle the two systems uniformly, although I don't know if it will work with the GUI libs, then you can take a look at Thor's action handling (http://www.bromeon.ch/libraries/thor/v2.0/tutorial-actions.html).
Title: Re: Tactics for handling Input Injection and Real Time Polling
Post by: zenroth on January 31, 2013, 04:58:11 am
Well the basic problem is, say I have a window displayed over my game view.

I click the window to do something with the mouse, the window gets the event and is happy, but suddenly the game also detects a mouse push (Since its using real time polling) and is trying to do things as well.

Normally I would explicitly handle this via game logic, but with using a GUI library that can be complex and tedious.

Really I suppose there are a lot of ways to handle this, I could just set a flag to not poll real time inputs if a input event is consumed this frame, or what not. Just wondering if anyone had nice clean solutions to this particular issue.
Title: Re: Tactics for handling Input Injection and Real Time Polling
Post by: eXpl0it3r on January 31, 2013, 10:59:43 am
Ah! I'd say it's a simple logic problem. Your GUI should actually only be open if a user demanded to open it, thus you know exactly the state of the GUI (open/close) and thus can handle events when the GUI is open, while not handling the real time input.
For example if you press 'm' the menu comes up and displays over the whole screen, thus you don't process game inputs, but only check for events.