> One problem here is that this is very recent work (only done in the > last few weeks) so the only example we currently have is the one > you've probably already seen that explicitly accesses the gles 2 api > via the vtable from cogl. > > I think a thing that could help you is providing a shim libcogl-gles2 > library that would provide you the standard glClear and glDrawArrays > symbols etc that osg can then link against so you don't have to worry > about jumping through the vtable. I've made a start on creating such a > library today so hopefully I can push this for you to take a look at > soon.
Just a quick update; i've pushed some new work-in-progress patches to wip/rib/gles2-context that make a first stab at adding a libcogl-gles2 library that provides all the standard libGLESv2.so symbols. It will be built and installed by default if cogl is build with gles2 support enabled and installs a cogl-gles2-experimental.pc pkg-config file that should hopefully make it easier to be able to get something like osg to link against instead of libGLESv2. As well as adding the libcogl-gles2 frontend api, I also added cogl_gles2_texture2d_new_from_handle() and cogl_gles2_texture_get_handle() functions that should make it possible to share textures between cogl and gles2. Please see the cogl/cogl-gles2.h header for full documentation of the cogl-gles2 api. If you aren't using libcogl-gles2 then you now also need to explicitly include <cogl/cogl-gles2.h> to access the CoglGLES2Context apis - I've updated examples/cogl-gles2-context.c to do this. Hopefully this takes us a bit closer to easing integration of things like osg with cogl. Any feedback would be much appreciated, though sorry if I don't get back to you this week. kind regards, - Robert _______________________________________________ clutter-app-devel-list mailing list clutter-app-devel-list@clutter-project.org http://lists.clutter-project.org/listinfo/clutter-app-devel-list
