The SDK is too object oriented

I absolutely agree. The SDK is obviously being built as a larger suite of tools, using typical C++ idioms. So the resulting code is about 2% "hardware abstraction" while being a lot of boilerplate and support for flexible device enumeration, messages, threads, and even their own "stdlib" of containers, math, etc.

I've been going through it separating out pieces into 3 categories:
1. low-level hardware interface
2. high-level interpretation (sensor fusion)
3. cruft that really exists in any application anyway

The goal is to have a low-dependency (no threading, for one!) C library for abstracting the hardware (1), with tools (2) for building a higher level abstraction in whatever OS/language with your application's resources (threading/messages/etc).

I have my doubts about any maintainability of this, however, because the SDK is obviously going to change a lot and the changes will not be easily merged.

Perhaps it's a matter of taste and programming habit, but I really like the OO and abstraction structure of the SDK.
I think this kind of structure is far more maintainable than a bunch of global functions.

P.-S. I have just looked at the online references, I haven't play with the code yet (the download cannot complete).

"Nems" wrote:
I think this kind of structure is far more maintainable than a bunch of global functions.

I think a point could be made that there aren't (and don't need to be) a bunch of functions. Also, much of the webwork of abstractions in the SDK is stuff that exists in OS, libraries, and applications already.

Then again, maybe the point is that the SDK is suitable for some people to build C++ demos on top of, while others should just use HIDAPI and implement their own sensor-fusion... ideally leveraging a very thin layer of hardware abstraction for capabilities and tuning values.

You can create an abstraction layer of simplified functions to access the functionality conveniently. You only need to do so once.

I will be doing this. It's not a bad SDK. You should see the FBX SDK if you want insane object-orientedness.

once I have my abstraction layer all of my code rests on that layer. If they change the API (which they will) then all I need to modify is my abstraction layer.

Unfortunately I won't have my dev kit until May so I won't be doing this ny time soon.

It should only take a day or two to pull out all of the necessary functionality from the samples and reorganize it into the simplified abstraction layer.

Basically it would consist of: Initialize, UpdateFusion, with a structure containing all the data junk I want to get at, and then the camera/rendering/shader stuff.

Im not a coder so not really sure myself but good thoughts, you should offer it as feedback maybe in time they can have other options for the SDK, for me im just glad they have the unity plugin so once i figure it out i can easily just make simple demo scenes :-) good enough for me for now!

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.

"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.

I don't think it's a bad SDK personally, but when I had to port Quake3 to use the SDK (Quake3 is in pure C) I couldn't link statically to the SDK, so I had to create an intermediate DLL between them.. Real easy, 4 functions and it will do the job..

Honestly, I don't have my rift, so I couldn't test it yet, but it looks like this.. Good or not, I'll let you be the judge!

libovrwrapper.h

#ifdef LIBOVRWRAPPER_EXPORTS
	#if defined __cplusplus
		#define LIBOVRWRAPPER_API extern "C" __declspec(dllexport)
	#else
		#define LIBOVRWRAPPER_API __declspec(dllexport)
	#endif
#else
	#if defined __cplusplus
		#define LIBOVRWRAPPER_API extern "C" __declspec(dllimport)
	#else
		#define LIBOVRWRAPPER_API __declspec(dllimport)
	#endif
#endif

struct OVR_HMDInfo
{	
	unsigned      HResolution;
	unsigned      VResolution; 
    float         HScreenSize;
	float         VScreenSize;
    float         VScreenCenter;
    float         EyeToScreenDistance;
    float         LensSeparationDistance;
    float         InterpupillaryDistance;
    float         DistortionK[4];
    int           DesktopX;
	int           DesktopY;
    char          DisplayDeviceName[32];
};


LIBOVRWRAPPER_API int   OVR_Init();
LIBOVRWRAPPER_API void  OVR_Exit();
LIBOVRWRAPPER_API int   OVR_QueryHMD(struct OVR_HMDInfo* refHmdInfo);
LIBOVRWRAPPER_API int   OVR_Peek(float* yaw, float* pitch, float* roll);

libovrwrapper.cpp

#include "libovrwrapper.h"
#include <OVR.h>

using namespace OVR;

// Ptr<> AddRef'ed, AutoCleaned
bool               bInited = false;
Ptr<DeviceManager> pManager;
Ptr<HMDDevice>     pHMD;
Ptr<SensorDevice>  pSensor;
SensorFusion       pSensorFusion;


LIBOVRWRAPPER_API int OVR_Init()
{
	bInited = false;
	System::Init(Log::ConfigureDefaultLog(LogMask_Regular));

	if (System::IsInitialized())
	{
		int stage = -1;
		while (++stage > -1 && !bInited)
		{
			switch (stage)
			{
				case 0:
					pManager = *DeviceManager::Create();
					if (pManager == NULL)
						return bInited;
					break;
				case 1:
					pHMD     = *pManager->EnumerateDevices<HMDDevice>().CreateDevice();
					if (pHMD == NULL)
						return bInited;
					break;
				case 2:
					pSensor = *pHMD->GetSensor();
					if (pSensor == NULL)
						return bInited;
					break;
				default:
					bInited = true;
					break;
			};
		}
	}

	pSensorFusion.AttachToSensor(pSensor);

	return (bInited?1:0);
}


LIBOVRWRAPPER_API void OVR_Exit()
{
	if (bInited)
	{
		System::Destroy();
	}
}


LIBOVRWRAPPER_API int OVR_QueryHMD(OVR_HMDInfo* refHmdInfo)
{
	if (!bInited)
	{
		return 0;
	}

	HMDInfo src;
	if (pHMD->GetDeviceInfo(&src))
	{
		refHmdInfo->HResolution             = src.HResolution;
        refHmdInfo->VResolution             = src.VResolution;
        refHmdInfo->HScreenSize             = src.HScreenSize;
        refHmdInfo->VScreenSize             = src.VScreenSize;
        refHmdInfo->VScreenCenter           = src.VScreenCenter;
        refHmdInfo->EyeToScreenDistance     = src.EyeToScreenDistance;
        refHmdInfo->LensSeparationDistance  = src.LensSeparationDistance;
        refHmdInfo->InterpupillaryDistance  = src.InterpupillaryDistance;
        refHmdInfo->DistortionK[0]          = src.DistortionK[0];
        refHmdInfo->DistortionK[1]          = src.DistortionK[1];
        refHmdInfo->DistortionK[2]          = src.DistortionK[2];
        refHmdInfo->DistortionK[3]          = src.DistortionK[3];
        refHmdInfo->DesktopX                = src.DesktopX;
        refHmdInfo->DesktopY                = src.DesktopY;
        memcpy(refHmdInfo->DisplayDeviceName, src.DisplayDeviceName, sizeof(refHmdInfo->DisplayDeviceName));        
	}

	return 1;
}


LIBOVRWRAPPER_API int OVR_Peek(float* yaw, float* pitch, float* roll)
{
	if (!bInited)
	{
		return 0;
	}

	Quatf hmdOrient = pSensorFusion.GetOrientation();
	hmdOrient.GetEulerAngles<Axis_Y, Axis_X, Axis_Z>(yaw, pitch, roll);

	return 1;
}

You might want to look at the Unity integration. It comes with a DLL that has a C style interface for binding to C#. That should work for most languages.

"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.