SDK 0.3.1 and compiling LibOVR to DLL

Here's another vote for shipping with dynamic libs (for all platforms). I'd much prefer dropping the prepared dll/so into my project than spending time compiling and testing myself.

"RiftingFlotsam" wrote:

For this release the SDK is still compiled as a static library. Down the road, that may change.

In terms of drivers, this may be necessary for certain features (i.e. for the camera).

viewtopic.php?f=20&t=7740&p=107827#p107827

Ah I remember reading about this but couldn't find where it was, thanks!

Sorry for bumping this thread, but it is the first result on Google for "LibOVR DLL" and I have a solution I thought I should share in case other have the same issue.

Rather than deal with mucking about in the project settings for LibOVR to make it compile to a DLL, I opted to make a small project that just "re-exports" the LibOVR static libraries in a DLL. Like you, my goal is simply to make a P/Invoke API for the new C API in SDK 0.3.x

I've attached my small Visual Studio 2013 project to compile LibOVRDll. It also includes binaries for all configurations of LibOVR. (For SDK 0.3.2)

If you want to build it yourself, extract the zip so your LibOVRDll folder is immediately next to the LibOVR folder. You also need to apply the small change to LibOVR shown below and rebuild it for x64.

I have not tested this very much as I do not have a DK1, but I did get the small sample from section 7 in the SDK overview "working" in C#. (It tells me the HMD isn't there...very exciting stuff :lol: )

As you found, someone at Oculus messed up their OVR_EXPORT definition. However, I don't think your fix is quite ideal since I think the #else branch of that is intended to leave out OVR_EXPORT on non-Windows platforms. Instead I just added a check for _WIN64 being defined:

diff --git a/LibOVR/Src/OVR_CAPI.h b/LibOVR/Src/OVR_CAPI.h
index ec4708c..c440265 100644
--- a/LibOVR/Src/OVR_CAPI.h
+++ b/LibOVR/Src/OVR_CAPI.h
@@ -34,7 +34,7 @@ typedef char ovrBool;
 // ***** OVR_EXPORT definition
 
 #if !defined(OVR_EXPORT)
-    #if defined(WIN32)    
+    #if defined(WIN32) || defined(_WIN64)
         #define OVR_EXPORT __declspec(dllexport)        
     #else
         #define OVR_EXPORT

Also, it seems there is a documented bug where SetThreadName corrupts the register state when called from unmanaged code being called from a x64 managed application that is being debugged from Visual Studio 2013 with unmanaged code debugging enabled. (Yes, the problem seems to be that specific.) As a workaround, I stubbed out Thread::SetThreadName in LibOVR/Src/Kernel/OVR_ThreadsWinAPI.cpp

Hi David, I forgot to add a link to this topic but I've released a NuGet package in .NET that uses the LibOVR dll described above: https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=8464&hilit=Sharpovr

I've also created a sample SharpDX project so anyone can create a rift game in C# without too much trouble. When Oculus releases their next SDK, I assume it will also be released as a dll so we won't need to be making changes to the LibOVR project.

Ah, I should have stalked your post history to find if you had solved it and didn't update this thread!

I glanced around the sample and your binding looks pretty nice! You might consider open sourcing it for people who want to tinker with it, who want to use it with something like OpenTK or SlimDX instead, or don't want to use NuGet.

Also, did you happen to run into that SetThreadName issue I ran in to? If not, I am curious what might be different in your setup that prevented it.

I've also tweaked the Oculus SDK to produce a DLL OVR_C.dll, or more specifically, produce a shared library on any of the three supported platforms. You can get it from my Github repository here. It requires CMake to create the project files, but then you can use your preferred build tool (assuming it's supported by CMake) to create the actual binaries.

"PathogenDavid" wrote:
Also, did you happen to run into that SetThreadName issue I ran in to? If not, I am curious what might be different in your setup that prevented it.

You know, I think I ran into this issue as well but couldn't figure out the source of the problem. Since it only occurred with the debugger attached and in 64 bit, I thought it was just a fluke and ignored it. Good catch! I've voted up your issue on connect.

As for releasing the source, there's very little code in the binding. Essentially I just mapped all the OVR methods to a static OVR class and all the HMD related methods to a HMD class. You can look at it through reflector/ILSpy. I'm not really into the whole GitHub sharing code thing but if you have any suggestions I'd be happy to include them.

@jherico

Thanks for sharing! Hopefully Oculus will publish official dll support eventually so we don't need to maintain such things.

I've voted up your issue on connect.

Not my issue, but thanks for voting on it! (I voted too.)

It was merely a suggestion for people who want to tinker with it without much effort. You are right though that it is very easy to bind the 0.3.x SDK to C#. I'm going to stick with my own binding just because I'd rather avoid the extra translation layer between my game and your stuff. :)

Since there's a new SDK and still not DLL support I guess it is time to re-awaken this topic!

0.4.0 does add a new constant OVR_OS_WIN32, which is now used to determine whether it should use OVR_EXPORT:

#if !defined(OVR_EXPORT)
    #ifdef OVR_OS_WIN32
        #define OVR_EXPORT __declspec(dllexport)        
    #else
        #define OVR_EXPORT
    #endif
#endif

Bad news is...OVR_OS_WIN32 is defined in OVR_Types.h, which is not included by OVR_CAPI.h D'oh!

So a little modification is still necessary. Otherwise, my method previously discussed in this thread still works, although LibOVR now depends on Windows Sockets (ws2_32.lib) and GDI (Gdi32.lib - for SwapBuffers)

Attached is an updated version of my LibOVRDll. As before, binaries are included and naturally it is only slightly tested.
Debug databases for release builds removed since I went over the file limit, so if you actually need them then you'll have to rebuild.

Of course, everyone is probably better off going off of jherico's repo once he updates it. ;)