Would like LibOVR.lib as a DLL

Sources and projects for LibOVR is provided in the SDK. you can duplicate the targets and change the type of the library to make your own LibOVR lib/dll combo then use your worklow on it.

You may also have to tweak sources to export the desired symbols. I do not have the source right now, but there is good luck they already put a macro in their function declaration, so a single line change. And if not, my recommendation is to put LibOVR in a git depot or other source control. Do the changes, and when they release a new version, integrate over it mergeing changes.

I managed to embed it such, that I have an access to a function such as this inside my program:

address = getLibOVRAddr("ovr_Initialize")

Now I can generate the headers and wrap this function with them, something I already had implemented for OpenGL.

I take that back. It didn't compile right even if at one point it already seemed like it would.

They have OVR_PUBLIC_FUNCTION(restype) in their declaration like you said. I'll take a look whether I'd manage to turn it into a DLL.

Looking at the code there seem to be flags to enable build of a DLL, but configuring it to actually build a DLL and add the preprocessor directives seem to just cause it to fail on undefined symbols on the linking stage.

"cheery" wrote:
In Lever I have workflow for importing shared libraries with automatically generated header files. I could do the same for LibOVR, but the LibOVR provides only the .lib that is statically linked file.

It would take some more elbow grease to enable the static linking of LibOVR into my interpreter. It'd be easier if it just was a shared library object. I'll try come up with a way to embed it in though!

I assume you're talking about using LoadLibrary to load the DLL functionality at runtime, because even with a shared library, if you're linking to it you still have to include the .lib file in your project.

However, it would be really really pointless to convert the SDK .lib file to a DLL. All the .lib file does is act as a tiny shim to open the actual Oculus library included with the runtime, which is already a DLL. Use the OVR_CAPIShim.c file as a guide to implementing code to load the actual runtime DLL and to load the function pointers from it.

Anyway, why would static linking be a problem?

I had the static linking fail. The RPython finds the Visual Studio version 9 compiler and sticks to it, and I tried to match it with VS2015 .lib This is the likely reason why it failed.

I had a look on lot of the things I have available, and I got to conclude the static linking is only a problem if it makes it harder to build Lever. This language has runtime sized in few thousand lines of clean and easy to understand restricted python. Pivotal thing is that you can afford to change it, if you decide to do so, I'd like that it won't present to be hard to compile.

Even if I could use statically linked modules in the same manner as shared libraries, using the approach I described earlier. I would still have to ensure there won't be conflicts that require relatively lot of end-user time to resolve.

So I don't need to really turn it into a DLL. :? I can generate the headers from the shim and link to the DLL that implements those functions. I'll try that method next.

Now if the symbols in the runtime library are same as in the shim library, I should be able to use the following headers to interface with it: libOVR.json

It'll take a while when the workday ends on my guinea pig computer. I'll tell updates about these efforts later.

Things are looking quite good. I opened LibOVRRT32_0_8 and it responded to ovr_Initialize and ovr_Create.

ovr_GetTrackingState returns a struct. That's causing me bit of agony, but it's one-time problem. It was about time I provided that part of FFI functionality anyway.

You may want to consider switching the signature of ovr_GetTrackingState to this:

void ovr_GetTrackingState	(	ovrSession 	session,
double 	absTime,
ovrBool 	latencyMarker,
ovrTrackingState* result
)	

"cheery" wrote:
Things are looking quite good. I opened LibOVRRT32_0_8 and it responded to ovr_Initialize and ovr_Create.

ovr_GetTrackingState returns a struct. That's causing me bit of agony, but it's one-time problem. It was about time I provided that part of FFI functionality anyway.

You may want to consider switching the signature of ovr_GetTrackingState to this:

void ovr_GetTrackingState	(	ovrSession 	session,
double 	absTime,
ovrBool 	latencyMarker,
ovrTrackingState* result
)	

Not very likely, that would break compat for older runtimes.
I mean, they haven't even fixed sensorData in ovrTrackingState using a float for TimeInSeconds since the CAPI was first released.

Well that struct-return thing isn't very bad. I solved it by allocating an automatically memory collected struct at every call. Since it's just one call every 10 milliseconds against an incremental garbage collector, I'm sure it won't bound my app performance anyway.

Here's a sample of how I call LibOVR now: https://github.com/cheery/lever/blob/ma ... us_rift.lc

Thanks for the help everybody.

If you like to follow where I'm going with lever, I've hopefully put up enough streams to allow that. If not, well, let me know what would you like.

"cheery" wrote:
Things are looking quite good. I opened LibOVRRT32_0_8 and it responded to ovr_Initialize and ovr_Create.

ovr_GetTrackingState returns a struct. That's causing me bit of agony, but it's one-time problem. It was about time I provided that part of FFI functionality anyway.

You may want to consider switching the signature of ovr_GetTrackingState to this:

void ovr_GetTrackingState	(	ovrSession 	session,
double 	absTime,
ovrBool 	latencyMarker,
ovrTrackingState* result
)	

I understand you have specific needs but please, return by value was already efficient and the way to go in c++ 15 years ago There is nothing worse that output values in arguments as pointer ( or reference ) in 99% of cases, and this one is not part of the 1%.