Any Linux devs? (and SDK rant)

I disagree about the resource allocations.

But the SDK is open source, so you can, and should, edit and improve on the official Oculus SDK if you don't like how it does things. The only restriction is that you can't add support for other HMDs directly to the Oculus SDK, you need to write your own sensor fusion, prediction, and timewarp for them.

"atavener" wrote:
I'm curious who's out there, how you're working, and what you think of libOVR.

I think it's overly complex, because one of the driving factors seems to be to minimize dependencies on other libraries. Some of that comes from the history of the OVR people and their customer base. If you're selling toolkits to other companies that might be developing for highly restrictive platforms like consoles, you don't want to be dragging in a bunch of additional dependencies and foisting them on your downstream customers.

However, I also think some of it comes from a not-invented-here syndrome. For instance, when the Oculus SDK release came out that first supported profiles, I was frankly shocked to see that Oculus had written their own JSON handling code. There's plenty of code out there with permissive libraries that wouldn't be cumbersome to integrate into the Oculus SDK. And because Oculus completely abstracts the profile API, third party JSON include code wouldn't have to be exposed in the Oculus headers. It would be an implementation specific detail hidden from downstream customers. But they went ahead and wrote a JSON parser anyway, meaning that some developer spent valuable man hours or days doing that, instead of, say, downloading and compiling this.

"atavener" wrote:
Then Oculus finally had Linux support. At that point, it's like everything (Linux) died.

Well, technically I ported the Oculus SDK to Linux and then like a week later Oculus released their own Linux support.

"atavener" wrote:
For myself, I didn't like the SDK for several reasons... but to not use it meant forging onward with opensource sensor-fusion or doing R&D of my own -- well, I'm not working on a game if I'm doing that!

Ideally, I'd like to hook into a sensor-fusion library (and perhaps config and other support routines) for Oculus products... without having this whole SDK. I'm not interested in (and doubt the value of) hijacking Oculus software for other hardware... but I'd like to minimize how much I'm wedded to Oculus software in general!

You should look at the new new C API. It's quite clean.

"atavener" wrote:
I recently gave another go... downloading the latest SDK. And was reminded of one of the issues: Xinerama requirement.

Actually Xinerama isn't a requirement of the SDK anymore. The example code uses it, but the SDK has switched over to using XRandR for identifying the Rift display. Again, something I did quite a long time ago in my community version of the SDK (in fact the implementation is suspiciously familiar, but that probably has more to do with the common examples out there in google-land). I imagine that DK2 has kind of forced their hand on this issue, since it's got a native resolution of 1920x1080, and so identifying the Rift solely by the display resolution is no longer a feasible option.

"atavener" wrote:
And ultimately I still don't like the SDK even if it's been given an "extern C" veneer over the C++.

I hate the code in Homeworld. I'm struggling with it because I'd like to adapt the game for the Rift, but I seriously hate the code. The nice things about most of the tools we use is that we don't have to see the ugly inner workings. You should really examine the C API on it's own, without thinking of it as an extension of the SDK. I've gone so far as to break out the C API code into it's own project... so the LibOVR codebase produces a static library, but the C API produces a shared object file that can be used independently with just the OVR_CAPI.h (and OVR_CAPI_GL.h file if so desired).

"atavener" wrote:
The SDK is still doing too much, does its own heap allocation and threads.

I fault the SDK for doing it's own JSON implementation. I also think that STL is a viable, and preferable alternative to the container and string classes they've written, but as I mentioned above, they have their reasons for avoiding STL. But heap management and thread management isn't something you can really avoid in many cases, if you're writing a cross platform library. Windows and non-windows platforms have vastly different APIs for threading, and unless you're willing to take a dependency like Boost (out of the question if you won't even take STL) or force all your users to go to C++11 (again, something of a non-starter in many cases), then there's no choice but to write a threading abstraction library.

Similarly, heap allocation can be a strange beast, and something that you can't always leave up to the OS. Especially in cases where you might be doing many hundreds of small allocations and deallocations a second, it can be critical to manage your own memory using pools, rather than overloading the OS memory manager, which simply may not have the performance you want for the access pattern you have.

"atavener" wrote:
The thing is, I develop on Linux, but I want to target many platforms (resource allocations should be provided by the host app/environment, not assumed by libOVR) and use a language which is not C++. The SDK is really built for developing on Windows/C++, and targeting Windows.

Actually, most of the things you're complaining about are specifically because the SDK was NOT built to target windows specifically, but was designed to target a variety of platforms, including consoles. The reason the SDK was windows only was because they had to build all the hardware interfacing code, and they could only do it one platform at a time.

"atavener" wrote:
I had hopes with the presentation earlier this year -- what looked like a more minimal C core, with additional SDK layers on top. Maybe that's still in development?

I think they're planning on providing some kind of helper layer on top of the C API, but the C API is in fact pretty minimal. You can hate on the underlying C++ implementation all you want, but as long as it works as advertised and the performance doesn't suck, you shouldn't let it stop you using the C interface.

Try taking a look at some of the example code for my book. Particularly this: https://github.com/OculusRiftInAction/OculusRiftInAction/blob/master/source/Example_2_4_HelloRift.cpp

"jherico" wrote:
Actually Xinerama isn't a requirement of the SDK anymore. The example code uses it, but the SDK has switched over to using XRandR for identifying the Rift display.

Doooooooooh!

I put too much trust in documentation. Here's a case where I should have just typed 'make' instead of reading the instructions first (which remind me of a Xinerama dependency).

It works.

Thank you for the up-to-date documentation, and likely being a positive influence on development, jherico.

"jherico" wrote:
But heap management and thread management isn't something you can really avoid in many cases, if you're writing a cross platform library.

Allocations and threads... I mean it shouldn't assume to use the OS. These are resources which an application should provide if needed -- the app hands off it's particular choice of resource management, OS or it's own. A basic driver for HMD shouldn't need any of this anyway. Leave the proto-game-engine and cross-platform device-enumeration to a higher level wrapper. The SDK is upside-down. Instead of a large featureset wrapped with a "clean C interface": a small C library with no dependencies optionally coupled with a featureful SDK which leverages it.

"jherico" wrote:
You can hate on the underlying C++ implementation all you want, but as long as it works as advertised and the performance doesn't suck, you shouldn't let it stop you using the C interface.

The thing is, the underlying implementation introduces dependencies: libstdc++, OS-based resource acquisition. And it does this because of "features" I don't want. The interface-based argument is similar to the problem with object-oriented programming: Here's the pretty interface! fine print: accessing some members may cause side-effects, corruption, stalls, spurious output, may not be suitable for multi-threading or re-entrance, and will certainly cause mutation.

However, I'll still go with your advice and move onward, now that I know I can at least run programs compiled with libOVR. I still don't like it, but this is largely ideological, as I probably won't be running any Rift on restrictive devices anyway... But when Linux is unsupported or my program fails to discover the Rift on someone's less popular distro, I'll be shaking my fist... :P

Thanks for the in-depth reply. I know you were driven by getting a Java wrapper working, from early on... and have been working extensively with the SDK to tame it for your needs. I wasn't nearly as motivated, though had similar interest: a development environment of Linux and OCaml from the start. I had warped stereo render and binaural audio ready on arrival of my Rift... after that it was an uphill battle and I eventually tuckered out.

"2EyeGuy" wrote:
But the SDK is open source, so you can, and should, edit and improve on the official Oculus SDK if you don't like how it does things.

Jherico did do this... (and the SDK is not "open source", but source-available). The reason I'm not interested in this approach is that I'd change so much that merging future changes would be a large burden.

If instead, the core library was merely the featureset which is unique to Oculus, that leaves the OS specifics, device enumeration, threading, etc to the developer! Or, the larger SDK for developers who are okay with the provided solutions. This way it would be easier for a developer to support arbitrary platforms of their choice, while leveraging Oculus features for Oculus products.

I'm a newbie programmer and a newbie linux programmer.

Perhaps this is naive but why don't you simply use a cross plattform librarys like SDL2 and boost for your application, and build it with that in mind, and after that just use the Oculus SDK just for Oculus stuff.

I don't see an issue with redundant code, at least not a practical one. If the ideological reasons are so strong I wonder you made it this far. :P

"ElectricMucus" wrote:
I'm a newbie programmer and a newbie linux programmer.

Perhaps this is naive but why don't you simply use a cross plattform librarys like SDL2 and boost for your application, and build it with that in mind, and after that just use the Oculus SDK just for Oculus stuff.

I don't see an issue with redundant code, at least not a practical one. If the ideological reasons are so strong I wonder you made it this far. :P

Wow. Sure, I might be stuck in a mentality suited to archaic consoles, rather than the modern "I don't care a whit about resources or code bloat".

But my real concerns are with relying on Oculus to handle cross-platform support, introducing dependencies which I don't otherwise need, and allocating resources which are better left to the developer for their specific use-cases and target platforms. By exposing a different API, built on a minimal core of hardware abstraction, rather than trying to make a plug-n-play-for-Windows API (and then "pImpl" it into other platforms), it would be easier for developers to support Oculus in existing engines and codebases which already target multiple platforms. They're doing their own thing, which creates a cross-cutting of system dependencies and potential breakage. "Hey, your game runs fine on my system, but it can't find my Rift!"

I do use SDL, and have for 15 years, as it's a nice, simple platform-abstraction.

"atavener" wrote:
But my real concerns are with relying on Oculus to handle cross-platform support, introducing dependencies which I don't otherwise need, and allocating resources which are better left to the developer for their specific use-cases and target platforms.

Well, most people (including me tbh) don't really want to develop platform specific code. And perhaps the same goes for OVRs developers.
I think that's the price to pay for PC development in general. Take any Linux Distribution as an example, you can't really complain about bloat (well you can but it doesn't help) everybody has to deal with it.

I'm not trying to defend OVRs decision to make the SDK the way it is, I'd prefer a zero-dependency native C/C++ library as well. But taking a pragmatic approach you have to deal with the idiocracy you are served to the best of your abilities, not "demand" the power to do as you want it.

"ElectricMucus" wrote:

I'm not trying to defend OVRs decision to make the SDK the way it is, I'd prefer a zero-dependency native C/C++ library as well. But taking a pragmatic approach you have to deal with the idiocracy you are served to the best of your abilities, not "demand" the power to do as you want it.

If there's no feedback, they don't know if anything is wrong. I was sending out a question, wondering if all the Linux devs have fled or given up. There hasn't been much response. Mind you, I rarely look at these boards myself.

Originally I didn't expect any software -- just the HMD. I was cool with that. When we finally received the Rift there was an SDK -- Windows only, but I that's okay I'll do my own thing.

Things changed when Oculus started investing in the sensor-fusion part of the software, and making it clear that they have vested interest in this. At that point, I wanted to be able to leverage the software side of Oculus products paired with their hardware -- otherwise I'm left making Oculus products behave potentially worse than they can be. I considered branching -- making a derivative "driver", but I estimated that keeping it up-to-date would be too troublesome when Oculus might leverage whatever bits of their larger SDK in a new portion which doesn't need to be written that way, but hey... that's how hairballs grow.

So, I dealt with the hand given, for a time. Then I reached a point where it wasn't worth it -- and backburnered the Rift. This was a point where I had bit of a game, not using the Oculus SDK... but saw that I needed to leverage the software side of Oculus. However, at that time, I couldn't even get the SDK to work with my system. This is for a system they somewhat kind-of support -- what about a console, tablet, or other device down the line -- I'm locked into whatever Oculus decides is worthy? This is where I get frustrated.

Certainly, Oculus should make a plug-and-play SDK -- as a separate, optional piece on top of system-agnostic Oculus-specific features (ie. USB packet structure and sensor fusion). Then you can use their ready solution for Windows, and someone else can make the low-level stuff work on their console device, NetBSD, or whatever the developer fancies. If the developer has a cross-platform engine which already enumerates USB devices with aplomb and handles thread resources and memory in its own special way -- they can happily leverage the low-level Oculus bits on all the systems their engine supports rather than butting heads with this SDK come proto-game-engine.

I'm not demanding anything of Oculus. I'm raising issues, stating my preferences, and wondering what other developers are thinking. Don't place that entitlement syndrome shit on me. If we accept everything silently, without communication, then what are we left with? A whole stack of ugly and brittle workarounds, like much of our software development. See, the reason I was curious about other Linux devs, is because if they've given up I might not bother either. But I got some useful advice from jherico -- at least I can run the SDK on my system now. Though I'm still dubious about relying on Oculus to carry the burden of system support. Other things I bring up don't stop me now, but are minor pain-points which might be problems later.