Freestyle Coding

You know those seemingly random Guids? Guess what? They're not random.

I'll give your head a moment to recover from that bombshell.

Ok, back with me? Good.

I was digging DEEP in some hardcore specs when I stumbled upon this. I had a situation where I have a Guid as a unique identifier. This identifier had some subsequent child data that needed to refer to the global object but required different handling. Yes, I'm being slightly vague. I do have to respect company proprietary data.

Due to this dilemma, I had a really weird "hash table" to quickly find the identifier from the child object. While this solution worked, and was REALLY fast, it was very messy and complex. I decided I needed to hack something to reduce this complexity.

I know. I just said I wanted to reduce complexity, and that my solution was to hack Guids. The sick humor of this is not wasted on me. You knew what you're getting into when you read my blog.

Turns out, there is a status field in the Guid. I was scouring the Wikipedia article on Guids when I read the Binary Encoding section. Turns out 3 of the bits have a special meaning. More specifically, if you were dealing with the Guid 00000000-0000-0000-x000-000000000000, part of the hex value of x means something. Guids in .NET, generated by the System.Guid structure, are all "standard" Guids. As such, they will always have the bit mask of 00000000-0000-0000-8000-000000000000.

If you don't believe me, go do a select on your largest database column. That hex value will always be either 8, 9, A or B.

If we exploit this, we now have 2 bits in our 128 bit number which we can control. We know those 2 bits being 10 will refer to our master identifier. However, since they are fixed, we can use 00, 01 and 11 as attached, but still unique, child Guids. This child Guids will always point back to the parent Guid by restoring those 2 bits to 10.

Happy Friday, people.

Hi, guys. I know I've been in hiding lately. I'm not dead. That status is saved for XNA (oops, did I say that out loud?)

I'm juggling quite a few project right now; all these projects have fixed deadlines. As such, I haven't had time to create the blog posts on them. Add that to my attempts to move all my old XNA sample code to new technologies.

In mid-May, my schedule should free a little. At that time, you should start seeing posts on the following topics:

• Using an Xbox 360 controller in a managed code Windows Store App
• "Recreating" the XNA game loop in a Windows Store App
• Data binding to attached properties (ie: Canvas.Left)

I'm sure there are more, but my mind is temporarily drawing a blank. Took much late night coding over the past month...

I also wanted to give you a quick heads-up over some of the events coming up.

• Code PaLOUsa : April 25 - 27 (Kinect and my last XNA talk...)
• Tampa, FL: May 7 (Games for Windows Phone)
• Tallahassee, FL: May 8 (Games for Windows Store Apps)
• Mobile, AL: May 9 (Games for Windows Store Apps)
• DevLink : Aug 28 - 30 (Schedule not finalized yet)

I should know it I'm working at TechEd North America on Friday. I have sessions submitted for That Conference and CodeStock. I should know about That Conference on May 1st. You can help me get to CodeStock. If you go and register on the Early Bird Special, you can vote for the sessions you want. Not saying you have to pick one of mine, but pick one of mine...

Speaking of CodeStock, there is a special engagement going during the event. While I'm up there, Michael Neel and I are going to give a joint session to the Knoxville Tech Co-op. It will be a post-mortem on XNA. We're going to talk about what it did right, what it did wrong, and what's next. As soon as I have details I'll post them here.

That's all for now. Keep the good comments and feedback coming. I love hearing from you guys.

Last night, I was playing around with my port. I was having a bit of a problem getting the mouse click to behave as I expected. In a fit of inspiration, I solved that problem in such a way that it allowed me to dramatically improve the keyboard buffer. With the popularity of the keyboard buffer, I thought I'd share right away.

As I stated in the original post about the keyboard buffer, WinRT doesn't route keyboard events unless there is a valid target. This forced me to have a control that required focus. This wasn't really a problem, unless the control lost focus.

Of course, we have to place our control on the screen. Furthermore, we have to place it on some sort of monolithic control that handles everything. Thus, why don't we just ask the Canvas to pass us these events?

Now, I just go up the chain and find the Canvas. At that point, I attach to its events. This way, I always get them. Mouse clicks, screen manipulation, throwing your Surface across the room? Doesn't matter. The events are bound so far up the chain that you always get them. You don't have to focus on the focus.

If you are reading this article without ever reading the original article, there are a few other things I'm leaving out. Check out the original post about the keyboard buffer if it seems like I'm not mentioning something.

This post should be considered part two of the series of posts called "Recreating XNA in Windows Store Apps." I'm basically creating a DrawableGameComponent. However, let's face it, I've discovered that titles like the about gets better traffic.

When we last left, we had an object that would update itself on a background thread at a periodic rate that vaguely resembled the functionality of the game loop. Now, we need to draw the object. The good news is that WinRT will automatically update the object on the screen at 60fps, assuming you don't bog down the UI thread. The bad news is that you can't directly update objects created on or controlled by the UI thread from a background thread. This also means, from all my experimentation, if we were to use data binding, raising the PropertyChanged event from a background thread silently throws an exception.

Given this limitation, we have to pull some real tomfoolery. We would like our object to update itself. However, we need to marshal the call to the UI thread. This is done through the Dispatcher property on a UIElement. This type of call is WELL documented online. As such, I'm not going into the ins and outs of this property. It is worth noting that I store the reference to the UIElement as it's superclass, a FrameworkElement. This will be explained in the next post, where I create new elements from a background thread.

To move our sprite, I need to update it's position on the screen. Once I update the position, the default WinRT draw, that defaults to 60fps, will do the actual update. To do this, in my setup, I need to make a call to Canvas.SetTop and Canvas.SetLeft. We dispatch our update to the UI thread as we always would.

Now comes my wandering into green, squiggly lines. I intentionally do not await my call to RunAsync. This forces execution to immediately resume on my background thread. All this comes down to timing.

Let's assume I have a 150 sprites on the screen. Let us also assume that I'm trying to update all 150 of these sprites in 150 background threads that wake up every 1/60th of a second. I'm going to end up stacking up a large number of small calls to the UI thread. If I were to wait my turn, there would be a strong chance that I would miss my update call. However, since I'm closing on the reference to the screen position, it should grab the newest version when I finally gets called. This does cause a scenario where the screen doesn't necessarily match reality of the position. However, if we miss an update, we still only are 1/60th of a second behind.

Once I get the screen FULL of self-updating sprites, I do want to try to move all the unblocking asynchronous calls to a low priority. Right now, with my low item count sample code, normal priority is working well. However, I don't want to flood the UI thread so much that I can't get the needed calls in due to a metric bazillion queued tasks. In theory, it should work well. However, I haven't done it yet, so I don't want to say it still behaves as suggested. Remember, we're learning some of these things together....

The next thing I want to point out is not strange, but it is a little obscure. I am maintaining a ReaderWriterLockSlim. If you've never seen this guy, it's a special kind of lock. It will allow as many simultaneous read as possible. However, once there is a call to write, it will let all the queued reads complete and lock the object for write until it is released.

And that, as they say, is that. As always, there is a comment section to let me know what I did poorly, either in explanation or coding. Now, go forth and abuse the thread pool.

It was unofficially announced yesterday that XNA has officially hit the end of its life. Fortunately, as mentioned in the last post, I'm working on porting everything out of XNA. However, there is stall a lot in XNA to love. As such, I have been making it a point to borrow some of the better features of XNA. Think of this post as the beginning of a series of posts called "Recreating XNA in Windows Store Apps."

The first thing I needed to recreate was a GameComponent. For those of you not familiar with XNA, a GameComponent is an object that updates itself during every cycle of the game loop. This helps to avoid a monolithic function that updates the entire game.

It is worth mentioning that I did, at one point, try to recreate a game loop in my Windows Store App. I stopped that experiment for two reasons. First, I wanted to try to treat the WinRT platform like the WinRT platform as much as possible. Second, you still have to call the UI thread for screen manipulation, so you're never going to get a true Draw phase. We'll go more on that second point in my next post, where I'll create a DrawableGameComponent. I think it is still possible, so I may return to the idea at a later time.

The first thing I had to attack was the concept of the object being called during every cycle of my virtual game loop. Traditionally, you would perform such an action by creating a thread, performing your update, and sleeping until it was time to do it again. However, this is a big no-no in a Windows Store App. You're really supposed to handle everything through the ThreadPool. I like monitoring threads manually as much as the next guy, so I opted to use his brother, the ThreadPoolTimer.

Using the ThreadPoolTimer, I can tell the thread pool to call my update function on a specific interval. The ThreadPoolTimer does include support for periodic timers, but I eventually moved to manual timers for reasons I shall soon disclose (I wasn't kidding when I said I like to manually monitor threads.) My constructor asks the App for the current target framerate and sets a timer. When my timer goes off and my update completes, I set a new timer.

The reason I don't use the periodic timer is twofold. First, I want to be able to be able to track some statistics about the system performance. XNA featured a class called GameTime that would report information about the clock to every call to Update. I wanted to use a few of those features. I created a custom set of EventArgs called UpdateEventArgs. These help me report the amount of time the thread slept. This allows me to do proper timing based events.

The other think I wanted to port from the old GameTime was a flag to notify that the game is running slowly. I put the IsRunningSlowly flag in the actual class and set if on each call to the timer. This guy gets set to true if the call to update takes longer to run than the current frame. This lets the component ignore a few things if the game gets a little hectic.

The last thing that was vital was a mechanism to turn off the component. This was easily accomplished with a simple property on the object called Enabled. If you set it to true, then the timer is created. If you set it to false, then the timer is canceled.

Once all this was in place, I created an event for the superclass. This is the event that will be triggered so the component can execute it's code.

I have a few quick notes about the preceding code sample. The call to App.FRAMERATE is a constant I declared so I could globally change the framerate if I need. Also, I convert everything to ticks for two reasons. First, integer math is much quicker than floating point math. Second, integer math does not have round-off errors.

So, there it is. Next up, we will base off this class to create a DrawableGameComponent. However, this will take some serious time, so you can digest all this. Plus, there is one little sticking point I'm trying to clean.

Let me know what you think. Comment away.

NOTE: I created a better version of this control. There are some important facts in this post that you should read first. However, check out Improved Keyboard Buffer for Windows Store Apps for a much improved version.

As I mentioned in my previous post, I came across a situation where I needed to create a keyboard buffer for a Windows Store App. I will now explain why I needed to do this and how I did it.

Windows Store Apps do some strange things with the keyboard. There is a completely logical explanation for this. WinRT is designed to work on devices that do not have a permanently connected physical keyboard. Since the system has to pop up a virtual keyboard if one is not connected, it plays a little tight on keyboard controls. This can be a problem if you are creating a game that uses a physical keyboard as a valid input device.

The first thing I tried to do was overload the OnKeyUp and OnKeyDown event on my main window. However, this does not work. WinRT on first the keyboard events if the control with the active focus can use a keyboard, such as a TextBox. This is really a problem for a game; I don't really want a control of that type to be displayed on the screen.

A little digging led me to discover that the lowest level class that can use OnKeyUp and OnKeyDown was a Windows.UI.Xaml.Controls.Control. However, this guy does have to be on the screen. As such, I made him one pixel tall and one pixel wide. Then I blended it to the background color and hid it in the top left corner of the screen.

Next, I had to capture all the input. In my experience, it's best to tread lightly when stealing events from the OS. As such, I look for the keys the concern me, process them as necessary, and make them as handled. If I don't care about the key, I just pass him along to the OS. There was one exception to this. I actively look for an Alt-F4 key combination. This is because I wanted to actively call Application.Current.Exit(). If you let the OS shut the app down, it decides to take about 10 seconds for the application lifecycle to defer termination in case you want to save state. I don't want this, so I did it myself.

I also discovered that I actually need to keep track of the keys that were down. This problem received its own blog post. It should be the post right below this, entitled This is not the OnKeyDown you are looking for.

The code includes a reference to IControlState. This is an interface I created to allow all the different methods of controlling the game to have a common interface. You'll see him pop up in other posts as I add additional input methods. I am omitting the code for him, but it's the same interface in my XNA talks and samples.

Soon, I'll show you how I'm using this guy to move my sprite. However, this post is long enough, and the next part will involve lots of threading. Let's leaving things well enough for now.

As always, if you have nay questions about the code up there, leave a comment. I'm sure there are a few strange things in there that I'm just not remembering at the moment.

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.

Greetings. Just a quick note that 99.9% of my CodeMash content is now up. Look in the sidebar under Projects, and got to GitHub Repositories.

Or, if you're lazy, click this: https://github.com/freestylecoder?tab=repositories

For the .1%, I took out the XACT project. I do not currently have a license for the song I use, which is fine for educational / fair use. However, I cannot, in good conscious, redistribute it.

Enjoy.

So, this just happened. I just took down an entire corporate network with bridged adaptors in Windows 8.

Let's back up.

Last night, I was preparing for my talks at CodeMash. When I give Xbox development talks, I have to use a strange network configuration. You see, to debug on an Xbox, you have to have an active connection to both Xbox Live and the development machine. The easiest way to do this on isolated conference wifi is to bridge the wireless connection to the wired connection of my laptop while using a cross-over cable to the Xbox.

However, this was the first time I've had to do it with Windows 8. So, I tested it all out last night and got it working. Thinking like any other laptop I've had, I left the connections bridged. Let's face it, on Win7 when you accidently duel inputted bridged connections, nothing really happens.

Let's back up.

I came to my attention a few days ago that the only machine I had capable of running Hyper-V was my laptop. My home laptop is a Pentium, and my work desktop is a Core Duo. Thus, all my phone development has to be done on the i5 work laptop. Due to this, I set up a docking station for my laptop so I could use better stuff while in the office. During this time, I pulled a network cable into the docking station.

Fast forward to this morning. I'm doing my usual work stuff. At some point, I put the laptop in the docking station. 10 to 20 minutes later, the entire corporate network goes tango uniform.

The network gnomes go into a furious round of creating ulcers that would make any doctor's eyes turn to dollar signs. BCBS and Tricare felt a disturbance in the force. Smurf just got real.

Four hours later, they managed to fix the network, but don't know what happened or how it was fixed. Hi-five were about, and many an M&M gave its life in the victory feast. There was just one nagging problem. The thing that worked shouldn't have worked.

The chief network gnome started trying to isolate the problem. In the process, he isolated one of the networks switches to pull it completely off the network. As soon as he did this, everything came back to life.

The problem being that the switch without a connection to the network was not only still connected, it was completely up and operational with the rest of the network. The only way this could have happened was if, somewhere on that switch, there was another router that had mysteriously been connected.

At this point, I raised both hands, triumphantly, and announced "IT WAS ME!" You see, any fool can take out a computer, it takes a programmer to take out an entire network.

The network connection in my office goes to a little four port switch. That connection goes to a few devices in my office. The other side goes to the isolated network switch. The adaptor for the corporate wifi goes to a different one of the switch. My laptop became the network gateway for the isolated switch.

Here is the moral of the story. Windows 8 does some thing new and unique when creating bridged connections. I creates a new adaptor called the "Network Bridge." This network bridge is a software router. It then connects the two bridged connections, using the one as a gateway for the other. However, in this case, this software router is a full blown router, DHCP server and all. Thus, my laptop created a HUGE feedback loop in the network. When we isolated the connection, it became the gateway for a large portion of the corporate office. We unplugged the network cable from the back of the docking station, and everything when back to normal.

I have not, yet, seen this documented in such a way. As such, I hope us figuring out this new way of bridging connections in Windows 8 can keep you ulcer free, doctors clear-eyed, and health insurance companies coming for you in a manner similar to the Empire.

Although I don't think I ever mentioned it here, I was selected by Microsoft Learning to be a MCT Regional Lead for the Eastern US. Basically, it allows me to be a conduit between people and Microsoft Learning about all thing training. Considering 90 people, worldwide, where chosen for this program, I am quite humbled to be selected.

Anywho, my good friends at Microsoft Learning asked me to write a guest blog post for them. Seeing as it was published this morning, I figured I'd give you guys a link to the article.

HTML5 Definition Complete: Be Ready for New Standards and Demands