Do you have plans to provide a SDK for developers? It could be great to have a C API allowing us to create some content for the headset. I think that a plugin for OSVR could be awesome. The Pimax 4K doesn’t have position tracking nor motion controllers. However with an OSVR plugin, it is possible to use the headset with Kinect (OSVR-Kinect plugin) and all sort of motion controllers.
If you want to talk about that, feel free ton ping me
I have a 64 bit version in: C:\Program Files\Pimax\LibPVRClient64.dll
And 32 bit version in C:\Windows\System32\LibPVRClient32.dll
and same 32 bit version in: C:\Windows\SysWOW64\LibPVRClient32.dll
Use the 32/64 bit version depending the program you intend to develop. Although I think you should use the 64 bit version if you’re on a 64 bit platform: in PVR_types,h it defines PVR_PTR_SIZE according to your OS. You could try setting it there to 4 (=32 bit) manually and use the 32 bit dll. But I’m not sure if that works.
“Also why don’t you directly call pvr_initialise() ?”
Look at PVR_interface.h. In pvr_initInterface() you see that it uses this function to retrieve the interface into the DLL. It then stores it internally and after that you can call pvr_initialise(). If you call pvr_initialise() without having called pvr_initInterface() I’m 100% sure it will crash.
You’re totally right ! LOL I missed that No need to call it manually, just start with pvr_initialise(), the call is included already.
Good luck, let me know how it goes ! I’m currently working on reverse engineering the FW myself, but I might mess around with the SDK too at some point.
Also, if you’re planning to develop for Extended mode, keep in mind that in Extended mode the headset simply emulates an Oculus DK2. So for extended mode you could simply use the Oculus DK2 SDK. Keep in mind though that only specific versions of the SDK seem to work with our headset.
“You don’t need a .lib file to use a dynamic library, but without one you cannot treat functions from the DLL as normal functions in your code. Instead you must manually call LoadLibrary to load the DLL (and FreeLibrary when you’re done), and GetProcAddress to obtain the address of the function or data item in the DLL. You must then cast the returned address to an appropriate pointer-to-function in order to use it”
That’s exactly what happens here. The code calls LoadLibrary and then uses GetProcAddress to obtain the address of the “pGetInterface” function. Next it calls this function, which returns the interface. The functions you call next are all part of this interface.
So don’t link the DLL statically. In fact you shouldn’t even tell the linker about the DLL I think. The whole point of dynamic linking is that you create the link to the DLL at runtime. It’s how viruses for example link a DLL to an exe at runtime.
Just make sure that the 32 bit or 64 bit version (depending on your platform) of the DLL is in the same directory as your exe and you should be fine.
Hehe. Ok. The error is because of a small mistake they’ve made. You need to remove the “PVR_EXTERN_C” twice from "PVR_API.h.
I’ve just tried it and then it compiles fine. It also seems to work since pvr_initialise() returns 0, which is pvr_success.
But, make sure you’re compiling 64 bits if you’re on a 64 bits platform (In VS2015: build/configuration manager go to active solution platform and change into x64). And then make sure the 64 bits version of the DLL is in the same dir as your exe.
#include "stdafx.h"
#include "PVR_API.h"
#include <iostream>
using namespace std;
int main()
{
int i;
PvrHmdHandle hmdh;
if (pvr_initialise() == 0)
cout << "success initialising" << endl;
if (pvr_createHmd(&hmdh) == 0)
cout << "success creating hmd" << endl;
cin >> i;
return 0;
}
It returns ‘success’ twice, so it created the hmd object successfully. However the device MUST be in pimax mode. If it’s extended mode, the creating of the hmd object will fail. If you want to develop for ‘extended mode’, you should use the Oculus DK2 SDK (make sure to use the correct version).
Good work, happy to hear it all works ! Good luck !
BTW Maybe you could share your progress here, I’m sure others would like to see basic code like how to read sensor data. Giving a little back to the community to progress it is always a good thing
I guess this is all people need, a small example of how to start the API and read sensor data. Happy we cracked that The more people start developing, the better. I’m still analyzing the FW itself, but I’m not sure if it will lead to anything just yet …
What do you want to do with the firmware? I think that it could be awesome to create a driver for OpenHMD. OpenHMD is a software that doesn’t require the original runtime for running HMD. You can use the Oculus Rift DK1, DK2, CV1 without any Oculus Software. However it’s extended mode only.
I think that a native driver for both OpenHMD and OSVR could be great. The current software just works, but it’s NOT optimized. Because it’s closed source, we can’t improve it.