Hi Robert,
You are right, Windows is missing most of the GL calls from 1.3 and on.
I'm using Win7 VS2015 with OSG 3.4.1.
...
Thank you!
Cheers,
Maxim
Thank you,
--Maxim
--
Read this topic online here:
Hi Maxim,
We just add #define as required rather than attempting to import all
features. As new GL features are added we may find temporarily a
#define is missed, when this occurs we add it as soon as we know about
it.
Not all GL headers are up to date so we generally have to backport
those
Hi,
Has this been resolved, or are there any news on keeping GL extensions updated?
I just ran into a problem where
Code:
#define GL_READ_ONLY 0x88B8
was missing from GL_VERSION_1_5 section. If GLEW was
included it of course worked.
So having extensions updated to 4.6 would be very
Hi Paul,
On Fri, Feb 5, 2010 at 8:43 PM, Paul Martz pma...@skew-matrix.com wrote:
2) Centralized management of extensions via external libs doesn't
fit well with the ability to
extend the OSG in 3rd party NodeKits, where the NodeKits support
extensions that that
the OSG version
Wojciech Lewandowski wrote:
Lots of older OpenGL extensions are now included in OpenGL specification
(rel. 3.2). I'd like to propose a small cleaning movement of OSG sources
Hi Wojtek --
I agree that the kind of scrubbing you've proposed would break backwards
compatibility, as Gordon
Good topic, Paul.
On 2/5/2010 9:02 AM, Paul Martz wrote:
There's the topic of centralization. I've proposed moving all OpenGL
function pointers an related initialization into a single class. Among
other reasons, this would make it easier for future developers to ensure
that they're
Paul Martz wrote:
(In fact, this is currently a bug in OSG. If I open a v3.0 context, OSG
uses the v3.2 core FBO entry points exposed by my device driver, not the
ARB FBO extension interface.)
Open mouth, insert foot: This is not a bug in OSG. As everyone knows,
FBO was part of v3.0. I was
Hi Paul et. al,
On Fri, Feb 5, 2010 at 4:02 PM, Paul Martz pma...@skew-matrix.com wrote:
Finally, another thing to consider is replacing our existing feature query
infrastructure with something like GLEW. GLEW is lightweight, easily
extensible, and already handles much of what we need for GL
On 2/5/2010 11:16 AM, Robert Osfield wrote:
For sure we can do better than what we currently do in an adhoc way,
but it absolutely has to do the job better than the likes of GLEW, it
*has* to decentralized, it *has* to support multiple graphics
contexts, it *has* to extensible. For all the
Hi Robert -- Thanks for your comments on this. I'd really appreciate
feedback on the other items I discussed in my email, before I proceed
with any submissions, so more input is welcome.
Robert Osfield wrote:
On Fri, Feb 5, 2010 at 4:02 PM, Paul Martz pma...@skew-matrix.com wrote:
Finally,
Paul Martz wrote:
1) Don't typically support multiple graphics contexts - a critical
issue under Windows as the
extension entry points can be different for each graphics context
Right, but something like GLEW might support multiple contexts.
For the record, GLEW does support multiple
Hi Everyone,
Lots of older OpenGL extensions are now included in OpenGL specification (rel.
3.2). I'd like to propose a small cleaning movement of OSG sources
Every time we submit a change of some OSG file we could also check for obsolete
GL extension: EXT, ARB, NV, ATI etc symbols and
12 matches
Mail list logo
