DirectXTK Keyboard and Mouse class good or bad?

Started by
1 comment, last by L. Spiro 8 years, 3 months ago

I was looking at how people handle mouse and keyboard input and came across a modern c++ library called the DirectXTK that contains helpers for writing games, specifically in direct x. I was looking at the keyboard and mouse class and was wondering if anyone has any experience with it? Does it have any limitations? Does it have any flaws that would fall flat on its face for handling a graphic/cpu intensive FPS?

https://github.com/Microsoft/DirectXTK/wiki/Keyboard

https://github.com/Microsoft/DirectXTK/blob/master/Src/Keyboard.cpp

Advertisement

It looks okay to me, but I'm going to suggest something else and for you to read this article http://www.gamedev.net/blog/355/entry-2250186-designing-a-robust-input-handling-system-for-games/ by ApochiPiQ. You basically have input contexts, input maps, buttons, and actions. Each different context can have a different map. Each different map decides which button corresponds to which action. An action is just the code that gets executed when it is activated, think function pointers.

So for example, Enter might mean select on a game menu, but in the game-world, it may mean to open up the chat box. You can also set different priority levels, so some actions may be unavailable for whatever reason. IE, you can't cast a Chaos Bolt (WoW :P) while you're in flying on your Ashes of Al'ar(also WoW).

This is also enables you to implement keybinding with ease. Changing input maps is as simple as loading up a new input map.

Hope I helped!

Its interface is polling-based (internally it is event-based). This has the obvious and very common problem of missing events. It is the easiest way to make your input feel sluggish and unreliable. If you game is running slowly, a quick release and press of the same key will not register as a new key-press event (if this library supports that at all anyway), and buttons you are holding will be held for the duration of a frame, meaning much longer than expected.
Furthermore, it does not time-stamp events. You have no way to know how long something has been held. Not only does this cause the above bugs, it means you would have to “hack” any charge weapons in by manually keeping track of when you detect held buttons. Due to the previous problems, this is impossible to do accurately, and your solution will never be stable.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

This topic is closed to new replies.

Advertisement