[osg-users] a question on extension functions convention

[Sergey Kurdakov]

Hi Robert,

after I wrote previous email I dug more into current emscripten way to
convert gl calls.

It looks like it is now possible to build working code with current osg
naming scheme for extensions ( unfortunately emscripten documentation on
these issues is  scarce, so I missed this possibility it in my previous
porting attempts).

Now I will make another round to convert osg with new approach and see if
it actually works for osg.

Thus disregard my first request.
Thanks for your time.

Regards
Sergey

On Fri, Apr 10, 2015 at 6:25 PM, Sergey Kurdakov <sergey.forum at gmail.com>
wrote:

> Hi Robert,
>
> you might notice, that I try to make a port of osg to emscripten
>
> Overall osg 'for  the web'  works, but I found several issues with
> emscripten which require me to keep
> quite a different copy of osg
>
> The main issue are  extensions.
>
> The problem arises from how emscripten translates OpenGL to WebGL calls.
>
> it takes
>
> gl* functions in C code and directly substitutes them  with webgl gl*
> functions.
>
> Now it is clear what the problem is : that emscripten compiler does not
> understand extension functions which are set in the way
>
> setGLExtensionFuncPtr(_gl*
>
> let's take an example:
>
> void Texture2DArray::Extensions::glTexSubImage3D( GLenum target, GLint
> level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei
> height, GLsizei depth, GLenum format, GLenum type, const GLvoid *pixels)
> const
> {
>     if (_glTexSubImage3D)
>     {
>         _glTexSubImage3D( target, level, xoffset, yoffset, zoffset, width,
> height, depth, format, type, pixels);
>     }
>     else
>     {
>         OSG_WARN<<"Error: glTexSubImage3D not supported by OpenGL
> driver"<<std::endl;
>     }
> }
>
> _glTexSubImage3D function won't be translated ,
>
> There are different ways to keep emscripten happy and use that
> glTexSubImage3D and I have forced it.
> But the ways how i did so far - looks patchy and inconsistent ( lots of
> '#ifdef's where calls to extensions occur )
>
> And I would like to have an osg port which is minimally different from
> stock osg ( just ifdef ed threading functions - there are no threads in
> browser and there will not be any similar threading functions to one used
> in osg for foreseeable future ).
>
> the  solution which will satisfy emscripten with least invasive way seems
> to have
>
> Extensions::_gl
>
> functions everywhere and also
>
> setGLExtensionFuncPtr(gl*  //no _ before gl
>
> approach to set extensions.
>
> and for setGLExtensionFuncPtr - for emscripten there will be a special
> function to deal with what gl functions WebGL has and what not.
>
> of cause I understand - such a change might break quite a bit of user code
> in case I develop a patch for osg which follows  such convention
>
> I have several other ways to deal - to write a special emscripten module
> which will be clever enough to use both gl and _gl functions during
> translation phase, but then - it is hardly possible that it will be
> accepted to emscripten as it will be needed only for my port and any user
> will need to hack emscripten to compile osg for web.
>
> so my question is - how feasible is to ask for _gl gl convention swap for
> extention _gl* functions and their Extensions::gl* wrappers?
>
> Best regards
> Sergey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150411/44a6d997/attachment-0002.htm>