Forum Discussion
SDK include issues
* The include files are in the Src folder rather than in the Include folder.
* All the include files require you to include "Kernel/OVR_Types.h" first, or they don't work. That is just silly, if they rely on OVR_Types.h they should include it themselves. I think the only thing they need from OVR_Types is OVR_OS_WIN32 etc.
* OVR_CAPI_GL.h requires wglext.h, glext.h, and gl.h. But the only thing it uses from them is a single usage of the type GLuint in gl.h, which you could have just replaced with an unsigned int and avoided all the OpenGL headers. I had to download and add wglext.h to Dolphin for no reason. You could even have just put all the OpenGL stuff in OVR_CAPI.h if you used "unsigned int".
* All the include files require you to include "Kernel/OVR_Types.h" first, or they don't work. That is just silly, if they rely on OVR_Types.h they should include it themselves. I think the only thing they need from OVR_Types is OVR_OS_WIN32 etc.
* OVR_CAPI_GL.h requires wglext.h, glext.h, and gl.h. But the only thing it uses from them is a single usage of the type GLuint in gl.h, which you could have just replaced with an unsigned int and avoided all the OpenGL headers. I had to download and add wglext.h to Dolphin for no reason. You could even have just put all the OpenGL stuff in OVR_CAPI.h if you used "unsigned int".
9 Replies
"2EyeGuy" wrote:
* The include files are in the Src folder rather than in the Include folder.
Yeah, this is the way it's been for quite a long time."2EyeGuy" wrote:
* All the include files require you to include "Kernel/OVR_Types.h" first, or they don't work. That is just silly, if they rely on OVR_Types.h they should include it themselves. I think the only thing they need from OVR_Types is OVR_OS_WIN32 etc.
* OVR_CAPI_GL.h requires wglext.h, glext.h, and gl.h. But the only thing it uses from them is a single usage of the type GLuint in gl.h, which you could have just replaced with an unsigned int and avoided all the OpenGL headers. I had to download and add wglext.h to Dolphin for no reason.
My version of the 0.3.2 SDK doesnt do any of that:
https://github.com/jherico/OculusSDK/blob/stable/Bindings/C/Include/OVR_CAPI.h
https://github.com/jherico/OculusSDK/blob/stable/Bindings/C/Include/OVR_CAPI_GL.h
It does require the user to include a GL header of some form before you include OVR_CAPI_GL.h and will produce a compiler error to that effect if you fail to do so."2EyeGuy" wrote:
You could even have just put all the OpenGL stuff in OVR_CAPI.h if you used "unsigned int".
No, you really can't. You can't ever assume that GLuint is the same as unsigned int. There are tons of platforms out there and tons of compilers, not to mention tons of OpenGL versions."jherico" wrote:
"2EyeGuy" wrote:
You could even have just put all the OpenGL stuff in OVR_CAPI.h if you used "unsigned int".
No, you really can't. You can't ever assume that GLuint is the same as unsigned int. There are tons of platforms out there and tons of compilers, not to mention tons of OpenGL versions.
No, there really aren't. Name one (which could run an Oculus Rift) that wouldn't work. Nobody is going to use an Oculus Rift on a 16 bit platform.
Anyway, the Oculus SDK already relies on unsigned int being 32 bits. See SensorDeviceImpl::onTrackerMessage for example.- We may be able to fix some of these things. Thanks for the feedback.
"2EyeGuy" wrote:
* The include files are in the Src folder rather than in the Include folder...
Even the primary include file "OVR.h" just contains pointers back to the Src directory. So it would appear that little serious effort has yet been expended toward separating interface from implementation for the SDK (as of v0.3.2).- You basically just have to include these files:
#include <GL/glew.h>
#include "OVR/LibOVR/Include/OVR.h"
#include "OVR/LibOVR/Src/OVR_CAPI.h"
#include "OVR/LibOVR/Src/OVR_CAPI_GL.h"
And#include "OVR/LibOVR/Src/Kernel/OVR_Math.h"
if you're working with matrix.
I've found that glew is kinda required because the SDK uses internally some gl features your project might not have included.
PS: the above is relevant for Linux. Should behave the same way for other plateforms but it is to be tested. - All valid points imo, and yeah, it's a little bit of a bummer.
0.3.2 also works on Visual Studio 9, with a bit of massaging. I understand you're not supporting the old Visual Studio APIs, but it's relatively easy to do, and saves me some money not having to upgrade my beggar home development environment. - Just piping in again that this is a solved problem in my version of the Oculus SDK. The C API has been broken out of the C++ SDK code, and has it's own include directory which is completely self-contained.
- One other thing I found a bit irritating is that
#include "OVR.h"
seems to indirectly include<windows.h>
on Windows, which means that it must be treated as an extremely delicate artifact, with surgical precision, and carefully limited scope, to avoid polluting other code with the many horrible side effects of windows.h.
@jherico does your version of the SDK avoid windows.h? Are you committed to maintaining compatibility with the official SDK for the next, say, two years? I'm interested in the prospect of accessing your repository in automated builds. I'm unaware of any other anonymously downloadable version of the SDK; so that's yet another attractive feature of your offering. "cmbruns" wrote:
@jherico does your version of the SDK avoid windows.h?
Neither my version nor the official version require Windows.h from OVR_CAPI.h. The core C API doesn't require anything beyond stdint.h. That's suitable for client-side distortion. If you want to take advantage of SDK side distortion then you need to include either the DirectX or OpenGL header. Because the SDK wants to perform the buffer swapping step itself, it requires an HWND, so indirectly it requires Windows.h, but doesn't directly include it."cmbruns" wrote:
Are you committed to maintaining compatibility with the official SDK for the next, say, two years? I'm interested in the prospect of accessing your repository in automated builds.
Well I'm not planning on abandoning it, and I'm using it to support the book. That said I don't tend to plan my life out for two years in advance."cmbruns" wrote:
I'm unaware of any other anonymously downloadable version of the SDK; so that's yet another attractive feature of your offering.
Just to be clear, It's still covered under the Oculus license, even if you can clone it anonymously.
