Hi Paul,
I've just reviewed your two sets of GL3 changes and have had to, for
now, reject most of them as they will just make the code less
maintainable by duplicating code paths unnecessarily. My approach
with the GLES support has to been to minimize the number of separate
code paths between all OpenGL targets as to avoid issues of code
quality, testing and maintenance. This does mean that one sometimes
has to look harder for opportunities to share code, or to localize the
target specific code paths to just a couple of lines, but it is
possible and in the long run will lead to a better OSG.
For instance, you have often replaced code like:
setGLExtensionFuncPtr(_glCompressedTexImage2D,"glCompressedTexImage2D","glCompressedTexImage2DARB");
With an GL3 specific path that reads:
setGLExtensionFuncPtr(_glCompressedTexImage2D,"glCompressedTexImage2D");
Where this should be totally unnecessary as the original code will
have done the right things already, as it'll check for the first
function name and succeded and then never both with the second ARB
version of the function name. This three parameters version of
setGLExtensionFuncPtr exist purely to help avoid the need for separate
code paths.
The changes I was expecting was to adopt the three parameter
setGLExentionFuncPtr more widely with the advert of GL3 and GLES3 have
these functions in the core. I was also expecting just to have to set
the enabling of the feature on by default in very local code segments.
I've counted 13 files in your submissions that didn't take these
opportunities, which is frustrating as it leaves us both with more
work to do to get things in a good enough form to merge.
At my end I'll see where I can easily change the code in svn/trunk to
enable things for GLES 2 and GL3 where it isn't right now, and use
your modified files as a guide to where you found problems. Once I've
done this I'll check the changes in, but as I only have GL2 and GLES2
+ GLES1.1 available to me right now I won't be able to test the GL3
path. Given that I don't have GL3 available I will hang back from
trying to make all the possible changes required for GL3, so once I've
checked my changes in you'll need to check the latest in svn/trunk out
and then review your original changes against svn/trunk and make
changes to the svn/trunk version that seek to minimize the number of
lines of code that differ across GL targets.
Cheers,
Robert.
On Mon, Nov 9, 2009 at 12:56 AM, Paul Martz <[email protected]> wrote:
> Hi Robert -- Here's part 2 of this submission, containing the more complex
> changes to Texture.cpp, State.cpp, and Drawable.cpp. Also a mod to
> BufferObject.cpp that I previously missed.
>
> Again, the basic idea is that, for any feature known to be part of core GL3,
> don't bother querying for the extension, and be sure to load only the core
> entry point address.
>
> Texture.cpp supersedes the same file in the previous submission.
> --
> Paul Martz
> Skew Matrix Software LLC
> _http://www.skew-matrix.com_ <http://www.skew-matrix.com/>
> +1 303 859 9466
>
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
