[ocaml-opengl] LablGL's Raw module
Török Edwin
edwin+ml-ocaml at etorok.net
Wed Mar 13 20:06:41 GMT 2013
On 03/13/2013 09:41 PM, Anthony Tavener wrote:
>
> On Wed, Mar 13, 2013 at 1:15 PM, Florent Monnier <monnier.florent at gmail.com <mailto:monnier.florent at gmail.com>> wrote:
>
> Also I've tried to use VBO with GLCaml, from a working vbo/hello-world
> from glmlite i've tried to rewrite it for glcaml, but I was unable to
> make it work. Does someone know if it's possible to use VBO's with
> GLCaml?
>
>
> Buffer objects don't work with the current (many years old) version of
> glcaml. One small change is needed to several functions: supporting
> an integer value as well as string/bigarray. For example, glVertexPointer
> needs to be capable of accepting an integer "buffer object name".
>
> In response to this mailing-list starting, and apparent interest in OpenGL
> with OCaml, I looked into the current state of things yesterday. Not much
> has changed... except you (Florent) have gotten a patch into LablGL for
> shader support -- hooray! And I also found someone else has added
> changes to glcaml/sdlcaml and posted them here:
>
> https://github.com/crackleware/glcaml
>
> A quick check shows that version has similar changes to what I've done
> locally, but it seems they changed the autogeneration program to make
> those changes, which is better. They also use glew, which appears to
I have briefly looked at OCaml last year, and had the crazy idea that the bindings should be auto-generated from these XML specs:
https://bitbucket.org/alfonse/gl-xml-specs/src
Those are quite up-to-date (OpenGL 4.3), and they are themselves generated by importing/parsing some files from opengl.org's registry
and fixing bugs in them.
The problem is that even if glcaml/glMLite was updated to use those XML specs as a source, it wouldn't be very useful without
a comprehensive unit test, or at the very least one test/function so that it was generated correctly (i.e. it doesn't crash).
And then there's the problem that it is quite easy to misuse these APIs, as they are after all C APIs. glMLite might be a bit safer here,
but I think you can still cause use-after-free bugs.
So my other crazy idea was that perhaps some higher-level bindings should be auto-generated that would call into the low-level bindings safely,
after all those XML specs do have *some* type information (and various objects could be wrapped in a record that tracks
whether they are freed or not and raises exception if they are).
This looked like quite a huge amount of work to do alone, so it all remained at the idea stage.
Maybe some day, when I have lots of time... :)
Best regards,
--Edwin
More information about the OpenGL
mailing list