2
\$\begingroup\$

So I originally had my input system set up with only the game part in mind. It listens to keyup/down events, marks the key as pressed/unpressed and then when the next update comes around, it sends out the state, and marks the current state as the previous state.

When I started implementing more complex UI elements, I realized this was a problem. Textboxes want to be notified of repeated keydown events so you can hold a key, scrollbars want repeated mouse down events, etc. On the other hand, the game only wants to know if a key is down and needs to keep track of the current/previous state for hotkeys and such.

What I would like to do is find a way to design the input system so it works for both cases. How can I support the repeating *down messages that the UI needs while also maintaining a current/previous input state that the game needs?

It occurs to me that I could perhaps just separate the two, using the input state manager only for the game input while hooking the UI manager directly into the keyboard/mouse input events. To me this seems less-than-ideal. For one, it seems a bit sloppy to be hooking the input in 2 different places. Also, doing so would remove the ability to send the current/previous input state to the UI. I'm not sure if this is even needed for the UI though. Maybe I'm just over-engineering things? I would like to have that ability if it's needed though. How have other people set up their input systems in such a situation?

\$\endgroup\$

1 Answer 1

Reset to default
1
\$\begingroup\$

There's no reason that the input system has to deal with repeat events. Your text input class can keep a timer and repeat keys itself if the key is held down. Same with scroll bars. Keep your state in the objects that care about them rather than pushing the logic into lower layers of the stack.

You can implement a reusable event state manage for GUI controls if you want to avoid code duplication.

Just store a repeat delay (how long the key/button must be down before repeat input occurs) and a repeat rate (how many repeat events should be sent over time).

\$\endgroup\$
3
  • \$\begingroup\$ I suppose I could do that, but it seems like a waste to filter out those repeats I'm getting from windows, hand the input to the UI and then have it recreate them. \$\endgroup\$
    – Telanor
    Commented Jul 26, 2012 at 22:24
  • \$\begingroup\$ It's more ideal to use the Windows repeats since those also follow user settings. However, you need a lot of infrastructure to get from the nasty Win32 API to something sane, and games rarely even try. Implementing it yourself is -easy-, and ignoring key repeat from Win32 is also easy. \$\endgroup\$
    – Sean Middleditch
    Commented Jul 27, 2012 at 7:54
  • \$\begingroup\$ That's probably true, but in my case it happens to be extremely easy to use those standard repeat events. The slimdx render form provides them as standard C# events. \$\endgroup\$
    – Telanor
    Commented Jul 27, 2012 at 9:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .