Re: [Caml-list] Pros and cons of different GL bindings ?

[Florent Monnier <monnier.florent@gmail.com>]

Le jeudi 28 avril 2011 02:32:06, Jacques Garrigue a écrit :
> On 2011/04/28, at 1:24, Anthony Tavener wrote:
> > Ethan's summary is good. I'll elaborate a bit on glcaml...
> > 
> > I use glcaml, but don't recommend it in general. There are two reasons I
> > chose it: 1. It looks like OpenGL, so my familiarity with it directly
> > translates... the only differences are lowecase GL constants and no
> > parentheses around arguments. 2. It (kind-of) supports features like
> > shaders.
> > 
> > What I mean by "kind-of" is that the bindings are broken for a lot of
> > lesser-used features. I've been maintaining my own modifications to
> > support features I need (same with sdlcaml)... though I recently decided
> > I should follow OpenGL 4 (basically the same as OpenGL ES 2), which
> > strips the interface down to a minimal set heavily reliant on shaders.
> > This is turning into "yet another set of bindings".
> > 
> > I know I tried glMLite... but can't remember what problems I encountered,
> > and I did encounter problems which led me to settle on glcaml.
> > 
> > Also, there is one other binding I know, by Jeffrey Scofield, for OpenGL
> > ES 1, and he uses this for iPhone development:
> > http://psellos.com/ocaml/lablgles-build.html
> > 
> > 
> > Summary:
> > 
> > If you don't need shaders: LablGL
> > 
> > If you want to do OpenGL ES 1.x (mobile device, for example): LablGLES
> > 
> > If you need shaders: glcaml or glMLite
> 
> Actually, LablGL has some shader support, provided by Florent Monnier.
> It has been in CVS for more than a year (file src/glShader.ml), but somehow
> I never came around to make a new release.
> I'm really sorry for the inconvenience.
> 
> If some people could test this code, this would be most helpful, and I
> could make a release in a few weeks.
> 
> Jacques Garrigue

I take the opportunity of this thread to ask to the users what 
they would prefer about this module (GlShader).
This is about all the functions which has a "count" parameter in the OCaml 
interface (and which wrap a C function which ends with the letter "v" for 
vertex probably)

http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
ocaml/lablGL/src/glShader.ml?rev=1.1;content-type=text%2Fx-cvsweb-markup

http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-
ocaml/lablGL/src/ml_shader.c?rev=1.1;content-type=text%2Fx-cvsweb-markup

The array data are currently provided to these functions in a *flatten* way,
and the question is maybe the users would prefer a more high-level interface?
A more high-level way would be an array of array or an array of tuples.

An array of tuples would be the safer but would probably not be the more easy 
to manipulate, while a tuple is immutable.

An array of array would need to check the size of every sub-array.
With these two alternatives, the "count" parameter would not be needed 
anymore.

Please tell us what you would prefer.
___

doc for glUniform* and glUniformMatrix* :
http://www.opengl.org/sdk/docs/man/xhtml/glUniform.xml
___

external uniform4fv: location:int -> count:int -> value:float array -> unit = 
"ml_gluniform4fv"

CAMLprim value ml_gluniform4fv( value location, value ml_count, value vars )
{
    int count = Int_val(ml_count);
    int i, len = Wosize_val(vars) / Double_wosize;
    GLfloat val[len];
    if (len != (4 * count)) caml_failwith("GlShader.uniform4fv: the array size 
should be a multiple of 4");
    for (i=0; i<len; i++) {
        val[i] = Double_field(vars, i);
    }
    LOAD_FUNC(glUniform4fv, PFNGLUNIFORM4FVPROC)
    glUniform4fv( Int_val(location), count, val );
    return Val_unit;
}

==============================

external uniform_matrix4x3fv: location:int -> count:int -> transpose:bool -> 
value:float array -> unit = "ml_gluniformmatrix4x3fv"

CAMLprim value ml_gluniformmatrix4x3f(
        value location,
        value transpose,
        value mat )
{
    GLfloat val[12];
    int i, len;
    len = Wosize_val(mat) / Double_wosize;
    if (len != 12) caml_failwith("GlShader.uniform_matrix4x3f: array should 
contain 12 floats");
    for (i=0; i<12; i++) {
        val[i] = Double_field(mat, i);
    }
    LOAD_FUNC(glUniformMatrix4x3fv, PFNGLUNIFORMMATRIX4X3FVPROC)
    glUniformMatrix4x3fv(
        Int_val(location),
        1,
        Bool_val(transpose),
        val );
    return Val_unit;
}