Unable to find documentation for SRWorks SDK C Api

[LS_Tpowell]

The sample application has been useful up to a point, but there's some missing documentation on a lot of things in the ViveSR_API header (such as ViveSR_GetPointer for example, which uses magic numbers for the second param that are not defines, consts, or references to an enum, though I assume is the datamask enum). Is there documentation for the C API itself somewhere? The included documentation is just of the behavior of the sample application and doesn't detail the API itself, and the included headers only have comments on three of the thirty-nine functions. Is there a newer version than 7.5.0 available, since this is the latest available on the SR Works download page?

[liyi_zheng]

your assumption is correct.

 

int ViveSR_GetPointer(int key, int type, void **ptr);

[out] error code. please refer the SR_Error in ViveSR_Enums.h

[in] key: the input value of callback function.

[in] type: the data mask enum. please refer module's DataMask in ViveSR_Enums.h

[in, out] ptr: function will change this pointer to point at correct data address according to key and type.

 

at first, register function to listen what modules you are interested. 

ViveSR_RegisterCallback(ID_SEETHROUGH, ViveSR:: SeeThrough:: Callback:: BASIC, GetDistortedCallback);

 

then, declare the function like below to get the data.

void GetDistortedCallback(int key)
{
 char *ptr_l;
 ViveSR_GetPointer(key, ViveSR:: SeeThrough:: DataMask:: DISTORTED_FRAME_LEFT, (void**)&ptr_l);
 cv:: Mat imgLeft = cv:: Mat(DISTORTED_IMAGE_H, DISTORTED_IMAGE_W, CV_8UC4, ptr_l).clone();
}

 

 for practical and detailed usage, please check the line 111 and lines 240-256.

[LS_Tpowell]

---

 wrote:

your assumption is correct.

 

int

ViveSR_GetPointer(

int

key,

int

type,

void

**ptr);

[out] error code. please refer the SR_Error in ViveSR_Enums.h

[in] key: the input value of callback function.

[in] type: the data mask enum. please refer module's DataMask in 

ViveSR_Enums.h

[in, out] 

ptr

: function will change this pointer to point at correct data address according to key and type.

 

at first, register function to listen what modules you are interested. 

ViveSR_RegisterCallback(ID_SEETHROUGH, ViveSR:: SeeThrough:: Callback:: BASIC, GetDistortedCallback);

 

then, declare the function like below to get the data.

void GetDistortedCallback(int key)

{

 char *ptr_l;

 ViveSR_GetPointer(key, ViveSR:: SeeThrough:: DataMask:: DISTORTED_FRAME_LEFT, (void**)&ptr_l);

 cv:: Mat imgLeft = cv:: Mat(DISTORTED_IMAGE_H, DISTORTED_IMAGE_W,

CV_8UC4

, ptr_l).clone();

}

 

 for practical and detailed usage, please check the line 111 and lines 240-256.

---

In Version 7.5.0 Line 111 of the ViveSR_Api.h is nothing, and lines 240-256 don't exist (and are unrelated in the only other included header)

[liyi_zheng]

for practical and detailed usage, please check the line 111 and lines 240-256 in Vive-SRWorks-0.7.5.0\C\sample-vs2015\main.cpp

[LS_Tpowell]

Just to clarify, ViveSR_GetPointer was a single example of the near forty undocumented functions. I'm asking if there's additional documentation available for the ENTIRE API not just this single function. I'm asking if we can get anything documenting the API in its entirety, I don't care if it's doxygen or just plain comments in the headers detailing purpose, fields, return data, exceptions, etc.. Yes, the sample application does an acceptable job of demonstrating usage, but having to return to the sample project EVERY time I want to see if there even is documentation (which generally there is not, see above conversation) while maintaining and reviewing our project is time consuming and frustrating. Please release actual documentation of the API, poorly commented and inconsistently written sample applications full of commented out code, to-dos, randomly placed header includes, and compiler warnings isn't something I'd consider "documentation."

[DaKenpachi]

I guess that´s why its Early Access. ;)

But I agree: If HTC wants us to try this library and give feedback, they should provide something we can really  work with. Plus - someone must have written this API. Why didn´t he just write some doxygen while doing that, it´s not much work and everybody would just profit from that!