Skip to main content
cheery
Up and Coming
January 18, 2016

Would like LibOVR.lib as a DLL

Hi

I'm the author of the Lever programming language.

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!

    12 replies

    Show previous replies
    galopin
    Up and Coming
    January 20, 2016
    "Rydier" wrote:
    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.


    And about that, the usage of double is not quite better, most high precision timing should remains in a uint64 counter.

    It was never more explicit than right now with dx12 : https://msdn.microsoft.com/en-us/librar ... 25(v=vs.85).aspx

    If we want every components of an app to sync with each other in the coming years, the rift need to talk uint64 for their time values !
    Rydier
    Participant
    January 21, 2016
    This is getting entirely off topic, but...
    I agree completely, but at least doubles, even when seconds are in unix epoch, maintain millisecond precision for quite a few years yet.
    Compared to floats, which, in the best case, start losing millisecond precision after 16 minutes of use, it's a big step up.

    IIRC from reading source when the SDK was still open, there were some pretty zany float casts of equivalent C++ fields when converting to the CAPI structure (way to resolve compiler complaints!), and quite a few comments in various other places that, for whatever reason, TimeInSeconds could not be relied upon as an accurate timestamp...
    Terms & ConditionsAccessibility statement