I've been working on porting my sample game code to WinRT. One of the immediate things I found is that there is no direct access to the keyboard buffer. I mean, sure. WinRT is meant to work with devices that don't have keyboards, but that's no excuse.
So being the
bourbonred-blooded geek I am, I decided to implement my own. Most of this process is not for this post. My next post will show this whole process and include lots of sample code. However, there was one part that was so evil, I decided it would get its very own post.
In order to do this, I needed to trap OnKeyDown and OnKeyUp. While doing this, I look for specific keys, handle them and pass the rest on to the framework. Basically, when I get the OnKeyDown event, I look for an arrow key and move the sprite as necessary. Go look at my XNA KeyboardControlState example. I'm imitating that.
As I'm testing this, I noticed a
bugundocumented feature. The sprite moves as expected for about half a second. Then, it goes into HYPER-SMURFING-SPEED! This would be awesome, if intended. Unfortunately, I'm too lazy to document it. Thus, I decided to remove the feature.
I decided to use one of those nifty Visual Studio features and set up a conditional breakpoint. I know, I'm high-tech. I told the breakpoint to fire on the second hit. I run the app, I press up, I hold up, I wait half a second, I get a breakpoint.
Some of you have figured this out by now. The first one of you that says "Sticky Keys" gets smurfed.
I've been operating under the assumption that OnKeyDown gets fired when the key is pressed down, and OnKeyUp gets fired when the key is released. I'm pleased to announce that I was half right. However, OnKeyDown is not tied to the physical key press. It's tied to the keyboard driver sending a keystroke to the framework.
The entire process was fixed with a List. Yes, there are more elegant solutions. However, when you see that List sitting it the class, there is no denying why it is there.