]> 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