Following on from my previous posts;
and, again, highlighting the official videos and samples for the Kinect for Windows V2 SDK bits;
I thought I’d continue my own journey in playing with these bits by attempting to move the code that I built up in the last post above into the world of a Windows 8.1 app as everything I’ve done so far has been in the context of either a WPF app or a console based app with both running on the “full” .NET Framework 4.5.x.
Those are very valid scenarios but one of the things that I find really interesting around the SDK is the possibility of building Windows Store apps and using the Store as a sales/distribution mechanism (NB: this will be possible when the SDK ships, you can’t do it on the preview SDK right now).
So, in moving the code that I’ve been playing around with for skeletal tracking towards a Store app, I needed to make what I think most politicians these days call “some tough decisions” in that the code I’ve written so far was attempting to draw in both 2D and 3D and the 3D part of that was making use of WPF’s 3D support.
Of course, you can do 3D work in a Windows Store app in a number of ways (Direct3D and various libraries on top of it) but while I know a tiny bit about WPF 3D I know much less about D3D and so didn’t want to take the hit of trying to get the 3D bits working just yet (there are samples in the SDK that do it).
For now, I decided to focus on getting the 2D code moved across from WPF to a Store app and, with that in mind, I made a Windows 8.1 app from the blank project template and made sure that I’d updated the manifest to allow for microphone and camera access;
Then I made a piece of UI which was pretty much the same as the one that I’d been using in WPF except that I put some buttons onto the app bar rather than on the screen;
I made sure that my project was referencing the right Kinect SDK library. As I’m going from the “.NET” to the “WinRT” world here, I’m actually moving from one set of APIs to another but, given that the SDK team have worked hard to present the same API “surface” this means that I shouldn’t have to do too much work to get my code across and it should largely be a copy-paste exercise.
As an aside, this does mean that you’d struggle to build a single binary library which referenced the Kinect bits and which was then portable across both Windows Store/Desktop because the underlying pieces are different. The solution (for me anyway) would be to build 2 libraries which presented the same API surface.
Anyway, I referenced the WinRT APIs for Kinect;
and this means that I’m bringing in a dependency on native code so I also changed my build configuration so that rather than targeting “Any CPU” I was targeting “x86”;
and then I set about bringing the code that I’d already written into this environment.
Doing so was reassuringly quick and easy with maybe 2-3 things that I had to take care of;
- Changing namespaces to use the WindowsPreview.Kinect namespace.
- Changing my code so that it went back to thinking only in 2D rather than 3D because in my last post I’d built an abstraction that modelled everything in terms of 3D space whereas now I’m back to thinking only in 2D.
and that was pretty much it in order to get the code up and running.
I suspect I’d also have to give some thought to life-cycle management and what implications that has for obtaining/releasing the sensor but I haven’t done that at the time of writing. Here’s the code running in a Windows Store app;
And that was pretty much it – the APIs in terms of talking to the Kinect seem to be the same here which is great and because I’m just drawing Ellipses and Lines to a Canvas that part of my code moves WPF->Windows 8.1 App as well without effort.
Clearly, where I’d have to make changes is around the 3D pieces as I don’t have anything that provides a replica of “WPF 3D” in a Windows Store App.
I won’t dump out all the code in a listing here because it’s 98%+ the same as the previous blog posts but that code is available here for download.
Thu, Aug 14 2014 1:03 PM