APIs which take a ptr (ptr void) generated only as (ptr void)
For example the params here is an output, but in the OCaml API it seems to be only an input: void glGetBufferPointerv(GLenum target, GLenum pname, GLvoid ** params); val get_buffer_pointerv : enum -> enum -> (nativeint, Bigarray.nativeint_elt) bigarray -> unit
Yes, the reasons are that:
- I was too lazy to bind it manually
- If you want performance you don't specify pointers directly but use buffer objects, so what you get it here is the integer offset, mostly like 0 that you specified in glVertexAttribPointer (hence the bigarray of nativeint)
- If you want performance you avoid to glGet* as much as possible anyway
- If you really want the pointer you can still convert that integer to a pointer using ocaml-ctypes.
A warning was supposed to be written in the docs for the 5 cases where this happens, but I forgot it for glGet BufferPointerv, glGetPoinzerv, glGetVertexAttribPointerv. It's there for glMultiDrawElements and glMultiDrawElementsBaseVertex.
Mmmh in fact it seems I'm wrong on 2) what you get here is a pointer on the mapped buffer, if it's mapped.
Ok so I may need to change it and return a bigarray instead, this means we need to add size parameter (i.e. the client has to know the size, see e.g. map_buffer vs. glMapBuffer). I'll also check for the other Get_Pointer. For the glMultidrawElements_ functions you may want to have a look at the warning in the docs.
That said I'm not sure I see the rationale for that function (or I'm missing something) as it allows other parts of the system to access a mapped buffer without the part that is mapping/unmapping actually knowing it. That seems a recipe for crashes, since the pointer becomes invalid once unmapped.
Look like glGetBufferPointerv should return the same pointer that glMapBuffer returned to you initially. I don't really see a use-case for it either (unless you forgot to save the pointer returned by glMapBuffer), so maybe just comment it out for now in the generated file.