The SDK is too object oriented

"jackwilliambell" wrote:

"Shul" wrote:

"longshot" wrote:
I'd prefer it if the SDK, at least the portions for directly dealing with the hardware, was written in C, instead of C++.

The reason being, is that writing bindings for other languages( lua, python, lisp, ruby etc... ), is generally trivial for libraries written in straight C. When libraries are written in C++, writing bindings can turn into an ordeal.

It is cleaner to wrap C code in C++, than it is to wrap C++ code in C. So my hope is that the lower level portions of the SDK could be done in C, thus ensuring the broadest amount of language support.

Wise words.

Complete and total agreement.

I third this. It makes a massive difference to language bindings. If you're going to make the SDK OS agnostic, make it language agnostic too!

If Oculus does provide a lower level C layer, not only is binding more sensible for other languages, but some dependencies can be removed. No need to have libstdc++ linked in, and no need for built-in threading. Threading can be provided by the application if it so desires threaded device or sensor handling... OR, the higher level C++ SDK with bells-and-whistles can be used. I think a simple C layer using HIDAPI would be a good basis for the larger SDK, but that might just be me. The hardware abstraction needed is tiny. What the SDK provides is closer to the beginnings of an app.

Regardless, this is the low level API I'm cobbling together (on hold until Rift arrives, so I can see that I've got HID stuff right). What I come up with will likely be just enough for my needs, and potentially troublesome with new hardware... so official support for a lean API would be very welcome!

"ecl3ctic" wrote:

"jackwilliambell" wrote:

"Shul" wrote:
I'd prefer it if the SDK, at least the portions for directly dealing with the hardware, was written in C, instead of C++.

The reason being, is that writing bindings for other languages( lua, python, lisp, ruby etc... ), is generally trivial for libraries written in straight C. When libraries are written in C++, writing bindings can turn into an ordeal.

It is cleaner to wrap C code in C++, than it is to wrap C++ code in C. So my hope is that the lower level portions of the SDK could be done in C, thus ensuring the broadest amount of language support.

Wise words.

Complete and total agreement.

I third this. It makes a massive difference to language bindings. If you're going to make the SDK OS agnostic, make it language agnostic too!

Yes, this would be a much better approach. Stacking the SDK in layers with a basic low dependency C API at the bottom and a full suite of C++ utilities at the top. That way you would be able integrate your applicaiton on what ever layer you would prefer.

"many" wrote:

"longshot" wrote:
I'd prefer it if the SDK, at least the portions for directly dealing with the hardware, was written in C, instead of C++.

The reason being, is that writing bindings for other languages( lua, python, lisp, ruby etc... ), is generally trivial for libraries written in straight C. When libraries are written in C++, writing bindings can turn into an ordeal.

It is cleaner to wrap C code in C++, than it is to wrap C++ code in C. So my hope is that the lower level portions of the SDK could be done in C, thus ensuring the broadest amount of language support.

"atavener" wrote:
If Oculus does provide a lower level C layer, not only is binding more sensible for other languages, but some dependencies can be removed. No need to have libstdc++ linked in, and no need for built-in threading. Threading can be provided by the application if it so desires threaded device or sensor handling... OR, the higher level C++ SDK with bells-and-whistles can be used.

I concur.

It would certainly simplify integration with something like libSDL (or Python), which would be an incredible boon for the gaming industry given its cross-platform nature.

"libsdl.org" wrote:
SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, C#, D, Eiffel, Erlang, Euphoria, Go, Guile, Haskell, Java, Lisp, Lua, ML, Oberon/Component Pascal, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk, and Tcl.

"atavener" wrote:
I think a simple C layer using HIDAPI would be a good basis for the larger SDK, but that might just be me. The hardware abstraction needed is tiny....

Regardless, this is the low level API I'm cobbling together (on hold until Rift arrives, so I can see that I've got HID stuff right). What I come up with will likely be just enough for my needs, and potentially troublesome with new hardware... so official support for a lean API would be very welcome!

Have you begun work on this yet? Hosted anywhere for collaboration (I don't have a Rift yet either)?

"JWB" wrote:

"atavener" wrote:
I think a simple C layer using HIDAPI would be a good basis for the larger SDK, but that might just be me. The hardware abstraction needed is tiny....

Regardless, this is the low level API I'm cobbling together (on hold until Rift arrives, so I can see that I've got HID stuff right). What I come up with will likely be just enough for my needs, and potentially troublesome with new hardware... so official support for a lean API would be very welcome!

Have you begun work on this yet? Hosted anywhere for collaboration (I don't have a Rift yet either)?

I just resumed last night, since I received a shipment notification.

I was initially trying to preserve as much as possible to make re-integration as sub-strata of the SDK easier, but I'm not sure that's possible. Win32/C++ and Patterns are about to drive me insane. I think the core functionality amounts to interpreting the HID packets and the display parameters. And on the graphics side... there really isn't anything but the distortion shader, right? Which is really just a polynomial warp, better done as a distortion texture, like lazydodo posted about.

The PITA is that there is a large volume of code to sift though just to figure out what's important. And then even the structs are C++-style with constructors and member functions, so all these little transformations of code takes time.

I don't have anything worth sharing yet... just a few C files that wouldn't compile and a file of notes that barely make sense to me. :)

Also note that this project wouldn't let you play any existing Rift demos/games. This would be for adding support to your own engine. The demos themselves are heavily tied to the SDK and D3D.

Well, crap: my connection dropped while writing a reply, and I didn't realize until after hitting preview.

"atavener" wrote:
...and a file of notes that barely make sense to me. :)

I can relate to that. I have an entire project dedicated to helping me create note files that barely make sense to me, which I'm intending to update with "semantic web" concepts.

"atavener" wrote:
Also note that this project wouldn't let you play any existing Rift demos/games. This would be for adding support to your own engine.

At this point I'm mostly interested in improving the cross-platform capabilities (OS and architecture), but I've made no progress in that regard.

"atavener" wrote:
The demos themselves are heavily tied to the SDK and D3D.

Don't I know it. I've managed to get the library to build, but I can't test it. I can get the SensorBox sample to fail looking for X11_Platform.h, but that's not exactly an accomplishment (i.e., not hard to do). I'm hoping the Minimal Oculus Application will build against the compiled library, which would confirm I'm not doing things completely wrong. It will probably make for a good testing point on a low-level C project, too.

"longshot" wrote:
I'd prefer it if the SDK, at least the portions for directly dealing with the hardware, was written in C, instead of C++.

The reason being, is that writing bindings for other languages( lua, python, lisp, ruby etc... ), is generally trivial for libraries written in straight C. When libraries are written in C++, writing bindings can turn into an ordeal.

It is cleaner to wrap C code in C++, than it is to wrap C++ code in C. So my hope is that the lower level portions of the SDK could be done in C, thus ensuring the broadest amount of language support.

I too would benefit from this.

The vast majority of my personal code base is pure C too (a requirement of my main client). Pure C is also easier to use for some embedded processors that have very limited resources (where C is almost a portable assembler language). Abstract features of C++ may be great for humongous team projects, but a very poor choice for many embedded apps.

I have been converting some of my code to C++, but it is a chore unless you use wrappers on every function (DirectX being an example of that, with the extra pointer indirection for C). I would MUCH MORE prefer a pure C SDK version, so please carry on with this noble conversion effort.

Thanks!

Here is a "pure C" version of the minimal app that reports Orientation and Acceleration data:
https://developer.oculus.com/wiki/Tracker_Data_for_C

This C program links to a minimal C++ wrapper module (included in the tutorial) that exports C bindings for initRift() and readRift() functions. Most other languages can call these C functions, including python, lua, VisualBasic, and many more.

The initRift() function in the wrapper module returns the RiftDK Windows display device name, which can be used to request (more accurate) system metrics using WinAPI calls.

Enjoy!

I like the interface: init, read. :)

Wrapping the C++ will at least help those of you choosing more sane (or even insane) languages on Windows. And creating a C-interface in this manner is easier to adapt to evolution of the OVR SDK.

I need non-Windows working (which the SDK might provide soon), but I also don't want to link with someone else's proto-engine (which the SDK seems to be), doing threading in it's own way.

This weekend I was distracted by stereo render and supporting offscreen render with a warp-map to bring it to the framebuffer. I figured this was a quick task, but time flies when you're chasing bugs... :/ But I wanted to at least have warped stereo view for my Rift's arrival today (yay!).

Now back to libusb and sensor data...