Re: [Caml-list] Announce: camlgl - OpenGL bindings for OCaml

[Nickolay Semyonov-Kolchin <snob@snob.spb.ru>]

On Friday 20 December 2002 20:28, Sven Luther wrote:
> >
> > http://www.sf.net/projects/camlgl
> >
> > Key Features:
> > - Full OpenGL 1.4 support
> > - All window system independent ARB extensions supported
> > - All published NVidia extensions supported (including NV30)
> > - All ATI extensions supported
> > - Windows and Linux version
> > - GLFW bindings
> > - unsupported Glut and SDL bindings
>
> Would you care to comment about the difference between your bindings and
> the lablgl bindings, 

Unsorted comparison:
- LablGL is a high level library build on top of the GL. 
- CamlGL provides direct GL bindings.
---------------------------------------------
/* C code */
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glRotatef(1.0f,0.0f,2.0f,0.0f);
glVertex3f(1.0f,1.0f,1.0f);

(* LablGL version *)
GlMat.mode `modelview;
GlMat.push ();
GlMat.rotate ~angle:1.0 ~y:2.0 ();
GlDraw.vertex ~x:1.0 ~y:1.0 ~z:1.0 ();

(* CamlGL version *)
open Gl
glMatrixMode cgl_modelview;
glPushMatrix ();
glRotatef 1.0 0.0 2.0 0.0;
glVertex3f 1.0 1.0 1.0;
---------------------------------------------
- LablGL (afaik) support all Ocaml enironments
- CamlGL (at present time) support only Linux and Windows (VC version)

- LablGL implements only a subset of OGL functions.
- CamlGL has full OGL support (with two exceptions)
glGetPointerv and glMultiDrawElements are not supported.

- LablGL has partitial GLU support
- CamlGL has no GLU support (and will never have)

- LablGL is a safe library
- CamlGL may produce "unstable" behaviour
I.e. if glGenLists or glGenTextures return value bigger than Caml max_int --- 
you are doomed. (Not possible with current NVidia & ATI drivers). You can get 
a segfault by giving incorrect array bounds for GL data, and so on. 

- CamlGL uses dynamic function loading which can cause trouble under Windows 
enironment. (This is poor theory)

- CamlGL produces very big executable files: ~700K under Linux, ~400K under 
Windows. (I don't care about that)

- CamlGL programs can be much faster than LablGL (VA, VAR, VAO, VP, etc)

- CamlGL can be integrated with existing C libraries without any trouble. 
(Bigarrays)

- CamlGL can be used for modern 3d graphics. (Vertex shaders, Pixel shaders, 
Multitexturing, VAR/VAO)

> the reason which made you implement a new
> alternative 

LablGL has no support for GL extensions and uses syntax very different from 
normal GL. 

>and the problems there would be in unifying both
> implementations ?

LablGL can be implemented on top of my library. 

> Would it also be possible to use it with lablgtk, do you think ?
>

Yes, I'am using it with lablgtk. I can send you description (cryptic) how this 
can be done. 

Comments, suggestions are always welcome.

Nickolay
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners