Input: Polling vs Events

[XerShade]

So was thinking the next thing I should do for my game is the Input system but not sure if I should do Polling or Event driven with Sfml. The way I was thinking about is having an InputController class in my engine and having that run first on the update cycle, that way it gets the input for the current cycle then does not modify it until the next, preventing some shenanigans from happening mid loop in some rare cases. The downside to this is that it's only done once per cycle, which means if the cycle takes longer for some reason then there is more lag on input.

 

Just for those who want to know, my game is written from scratch on a custom made engine, using SFML as its Audio/Video system and I will be using SFMLs input events if events should be used instead of polling.

[JimineyWhiskers]

i like to define actions and then group them up. for example, i would define a "PlayerControl" group with inputs like MoveUp, Attack, etc... actions can all share the same input buttons (keys.up, gamePad.X, etc...). thing is, you just need to handle which actions are on or off and add the ability to turn them on or off - then you never have to limit yourself to specific inputs, you can define your own. when you go to a menu, disable PlayerControl and then enable MenuControl for example.

 

Then you can define is an action is pressed or triggered, triggered would take a frame (or more) to register, pressed is instant. make sure you call your poll update first.

 

edit: Also, you could dedicate a thread to polling input if you're seeing cycles take longer. input is usually easy to make thread-safe as you only ever need to query it anyways. could even go as far as to store a list of inputs between clock cycles and instead of checking the current state you check against a collection of previous inputs. then you could utilize this to query for inputs like combos, etc..