Kinect for Windows (v1) with SDK 2.0 - kinect

I have issues installing Kinect for Windows (the V1 version) using the SDK 2.0. I'm assuming the SDK 2.0 also include drivers necessary for v1 since the download details says introduces support for the Kinect for Windows v2 sensor.
The issue I'm having is after plugging the kinect in the USB 3.0 port (the kinect is already plugged to the AC), it install the driver, but the device manager has the yellow triangle, and it keeps making the plugged/unplugged sounds.
Am I missing an step or should I use a different SDK version (if yes, which one)?

The kinect SDK 2.0 doesn't work with kinect for Windows v1. What you need are:
Kinect for Windows SDK v1.8: http://www.microsoft.com/en-us/download/details.aspx?id=40278
Kinect for Windows Developer Toolkit: http://go.microsoft.com/fwlink/?LinkID=323589

Related

Application development Windows Embedded Compact 7.0 for Motorola MC32NO

I am trying to get started on application development for my Motorola MC32N0 device running Windows Embedded Compact 7.0.
This tutorial explains that I need a Board Support Package (BSP), however I am unable to find this on the Zebra website. Is a BSP available for the Motorola MC32N0, and where can I find it?
Another question, during the installation of Platform Builder 7.0 I used a trial license key. Now if I deploy the build output to my device, will it replace the OS that is already installed, or will it just deploy the application?
I am new to Windows CE, but have a background in web development and WinForms.
For C/C++ application development, Visual Studio 2008 and the Motorola SDK will suffice.
BSP's on the other hand are for developers working on low-level code such as the kernel OAL and device drivers. Platform Builder 7.0 is a plug-in to Visual Studio 2008 that enables building and debugging BSP code, and is not required for application development either.
If you only intend to develop C# applications, you may not even need the Motorola SDK, but could target just a generic Windows CE device in Visual Studio.

Surface SDK only for surface

This might be a stupid question, but I couldn't find the answer anywhere. Does the Microsoft Surface SDK 2.0 only work with Microsoft Surface products, or can I use it with other touchscreens? I really just like the way the SurfaceTextBox control works (popping up a onscreen keyboard when clicked) and was wondering if I could use it in a program I'm making (which uses a Elo touchscreen monitor, not multi-touch).
Edit
Thanks for the responses. I downloaded and installed the SDK 2.0 and tried to run the sample apps that are included. They don't seem to respond to my finger touches but do work if I the included simulator. I'm running this on windows 7. Any reason why it doesn't seem to work on my touch screen?
Yes, you can use it with any touchscreen. It works on WinRT/Windows 8 as well as Windows 7. I have used it for surface, tablet (both WinRT as Win7 tablets) and touch-enabled desktop applications and it works absolutely fine.
The installer requires you to install Visual Studio 2010, but if you import the DLL's manually in the toolbox, you can also use it in both Visual Studio 2012 and 2013 preview. This is an answer on a different question, answered by one of my colleagues on how to use the Surface SDK 2.0 with Visual Studio 2012
It's a great toolkit to support touch-enabled WPF applications and can also be use as a replacement for the WinRT Metro UI, in case you cannot use that toolkit (e.g. when you interface with USB, or need desktop services).
Update:
Since you update your question to how to get the Elo Touchscreen to work with native Windows 7 touch, I suggest you download and install the latest drivers. Your touchscreen will only work with WPF touch / Surface SDK if native Windows touches are supported. Installing the latest drivers should do the job. Don't forget that you might have to enable and configure touch input in the Control Panel (Pen and Touch).
I noticed that in some cases touches are not working when you use a SurfaceWindow. Use a normal WPF Window and all the SurfaceControls should work. Thus if you want to use the sample applications on Windows 8 you need to replace SurfaceWindow with Window and remove the unavailable EventHandlers.
From Microsoft's web page:
http://msdn.microsoft.com/en-us/library/ff727815.aspx
The Microsoft Surface 2.0 SDK provides the managed APIs and the tools you need to develop Surface applications. Applications that are built using the Surface SDK can run on devices made for Surface 2.0, and on Windows 7 computers.
See also:
http://social.msdn.microsoft.com/Forums/en-US/b61c2eda-410e-4c65-9a60-b9e0a8ea11b2/windows-surface-sdk-setup-and-development-on-the-tablet-windows-rt
Surface SDK 2.0 is not dedicated to Windows RT for a Surface Tablet. it
is innitially dedicated on PIxelSense SUR40 unit or if you are bulding
windows 8 application with Pro version.
There has been a lot of confusion since the arrival of the Surface
tablet. The product name Surface before what the name of the Microsoft
Table touch table and the Samsung SUR40 device.
And that SDK was only working on those device. Then MS has release a
version (Surface SDK 2.0) which can be use also fro traditionnal Touch
PC application starting from Win 7.
Finally:
http://www.infoq.com/news/2011/07/Surface-2
With Microsoft Surface SDK 2.0 one can write applications for both
Surface and Windows Touch devices.
Surface 2.0 is not compatible with Surface 1.0 devices, and so far the
only compatible device is Samsung SUR40 [as of July 2011]...
These details have been public for a while, but Microsoft has just
made available Surface SDK 2.0. One of its key features is the ability
to target Windows Touch devices, that is Windows 7 computers with
touch input, so this SDK serves a much larger spectrum of devices. If
there are very few Surface devices out-there, there are lots of
Windows Touch ones, and their number is poised to grow.
Windows Touch applications are very similar to Surface ones, except
that the later supports full HD resolution and a multitude of touch
related inputs, such as finger and blob recognition, tagged objects,
tilted display, rotated display, etc.
At windows 8 you just need do that:
Run Microsoft Surface Input Simulater
Go to Device Manager
In Human Interface Devices, right click over Touchscreen compatible with HID and click activate.
Just that. ;)

Visual Studio 2012 thinks I'm on Windows 8 and demands libraries I don't have?

I implemented the code from one of the samples in the DirectX 11 SDK from June 2010.I open my project in 2012 and then I open the sample in 2012 too,however when I run mine,it requires XAudio2_8.dll.How is thsi even possible?That's the .dll in Windows 8 and the code from the SDK is from 2010 - such .dll didn't exist back then?The weirdest thing is the SDK sample builds and runs,while my project asks for the .dll.I linked all the libs,made all the includes,I checked around the project settings,searched the whole hard drive for such a dll,nothing...What could be causing such a problem?I've also been having all sorts of other problems in the SDK under VS2012,like not recognizing types in the dx11 headers and so on.
The Windows 8.x SDK has the DirectX SDK integrated into it, which for many areas means you don't need to use the legacy DirectX SDK at all. In particular, Direct3D, DirectSound, DirectInput, etc. all have the proper headers and libs in the Windows 8.x SDK.
The DirectX SDK is quite venerable, so there are a number of older things missing: no DirectMusic playback, DirectPlay, etc. I have a blog post that provides a full inventory of what happened to everything in the DirectX SDK.
Where it gets complicated is XAudio and XInput. Both XAudio 2.8 and XInput 1.4 are part of the Windows 8.x OS, but is not available on Windows 7. If you are targeting 'down-level' to Windows 7, you have to use XAudio 2.7 and either XInput 1.3 or XInput 9.1.0. This somewhat messy story is covered in two blog entries: one for XInput and one for XAudio. The good news is that most use of XInput is actually doable with XInput 9.1.0 which is part of the Windows OS starting with Windows Vista. It's XAudio 'down-level' that requires mixing the modern Windows 8.x SDK and the legacy DirectX SDK, plus having to use the legacy DirectX SDK REDIST (DirectSetup).
The root reason you are getting a 'runtime' error instead of a 'compile-time' error is that you didn't set _WIN32_WINNT to 0x0601 for Windows 7 (or 0x0600 for Windows Vista). If you had, the XINPUT.H header in the Windows 8.x SDK would automatically use the XInput 9.1.0 version and the XAUIOD2.H header in the Windows 8.x SDK would have errored out and told you it wasn't going to work for Windows 7.
Finally, I've cleaned up and reposted many of the old Direct SDK samples to MSDN Code Gallery in such a way that they don't need the legacy DirectX SDK.
The basic rule is, if you develop XAudio2 program on Win 8, use the Windows SDK, otherwise, use DirectX SDK.
If you are working on Win7, make sure
the head file XAudio2.h you are using comes from the DirectX SDK, that's something like C:\Program Files\Microsoft DirectX SDK (June 2010)\Include\XAudio2.h, not come from the Win8 SDK, something like C:\Program Files\Windows Kits\8.0\Include\um\XAudio2.h(in case you installed the Win8 SDK)
Call CoInitializeEx(NULL, COINIT_MULTITHREADED); before calling XAudio2Create, since the old version(before 2.8) of XAaudio2 was created by COM, so it does not need a .lib file, and there is no .lib file for XAudio2 before Win8.
This page below contains a detail introduction of the version of XAudio2, you can take a look.
XAudio2 Versions

Is it possible to use the Microsoft Kinect SDK with Metro Style applications?

I was wondering if it is possible to use the Kinect SDK with Metro Style applications and if smartphone and tablets will have support for Kinect.
I think it is possible and someone has done it. But not directly on Metro UI as far as I known (April 4, 2012)
Microsoft released Kinect for Windows 7 SDK in June, 2011. So, we know that Microsoft is targeting to utilize Kinect for PC controlling. Since Windows 8 is more touch driven than any other previous release of Windows, it should be in their target to introduce Kinect as one of the Windows 8 control device.
In addition, Metro UI has already been introduced on XBOX. We can see that Kinect works really well with XBOX Metro UI. Given that Kinect works well with Windows 7 and Metro UI on XBOX, it is not hard to imagine Kinect to work with Windows 8. Especially we know that most of the .Net 4.5 applications should still be working on the traditional desktop interface of Windows 8. (A video on youtube also demonstrated how they used Kinect on Windows 8 traditional desktop interface and Metro Application by using a service)
We've developed a project called "KinectMetroApp" that helps to use kinect to control Metro UI on Windows 8.
Plz find below the post that describes the project.
http://wiseteamtn.wordpress.com/2012/03/27/kinect-your-metro-style-app/
Also, a recent article on channel 9 speaks about this Topic.
http://channel9.msdn.com/coding4fun/kinect/Kinect-your-Metro

Developing for Kinect on the Xbox

I am working on building a prototype for an game that will eventually be commercial but is not at present. Since I am not a licensed Xbox developer, I don't have access to the official Microsoft XDK. I am aware of the Kinect for Windows SDK that was recently released, as well as open source alternatives like OpenKinect. Unfortunately both of those options are Windows only. I've heard that Microsoft eventually plans to release Kinect support for XNA, but who knows when that will happen. My question: In the short term, is there any library, clever hack, or open source alternative that I can use to get my prototype working on the Xbox itself?
No. The only way to do native development for the Xbox 360 is to become a registered developer. Your best option for building a prototype is to develop on the PC using the Windows Kinect SDK if applying for registered developer status is not an option for you. If you develop with DirectX 9 and stick to core Win32 APIs you shouldn't have too much trouble porting your code to the Xbox 360 later. The biggest thing to be aware of for porting is endianness issues.