OpenGL Extensions

Hi guys,

I’m wanting to implement some form of automation in respect to openGL
extensions.

Could someone confirm if the following would work on most/all openGL capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.–
View this message in context: http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.

Hi,

what would your automation offer that

GLEW (http://glew.sourceforge.net/) and
GLEE (http://elf-stone.com/glee.php)

don’t offer already?

If you are doing this to learn, then yeah, those functions
are working on most systems.–
Paulo

On Fri, Aug 7, 2009 at 6:20 PM, GMScribe <ali_lowe at sky.com> wrote:

Hi guys,

I’m wanting to implement some form of automation in respect to openGL
extensions.

Could someone confirm if the following would work on most/all openGL
capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.

View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’m looking looking for code that is up to date. GLEW and GLEE seem to have
hit a road block at openGL 3.0. I’ve checked the SVNs and these are also
lacking full support.

After looking at the code I’ve also come to the conclusion that updating
them would be a pain in the ass as how they’re written is a little all over
the place.

I’m considering, and yes partly to teach myself more about the basics of
openGL that aren’t usually exposed to me (I’ve used GLEW in the past), to
create similar code based on SDL’s existing functions like the one listed so
that I can create a maintainable system that shares SDL’s portability rather
than needing a slew of workarounds.

I’m also interested to see if people would like this feature as core to SDL.
As Sam mentioned in a previous post, the concept of SDL is to make a context
and get out the way so that people can use whatever extensions they like,
however, the biggest pain in the ass is that anyone using openGL above 1.1
has a load of core extensions to load and possibly some none core too,
ultimately leading to most of them needing GLEW etc as a necessity. If it’s
a necessity, why not provide it from the point of context creation? Possibly
as an optional flag or an extra function not requiring the including of an
extra API.

One other consideration was that now gl3.h exists, we may see some
compatability issues from users mixing future version of GLEW/GLee and
SDL_opengl.h etc so I’m wanting to pre-empt this if possible by having
complete control over gl.h/gl3.h includes. Just another matter to consider.

Many thanks,

Paulo Pinto wrote:>

Hi,

what would your automation offer that

GLEW (http://glew.sourceforge.net/) and
GLEE (http://elf-stone.com/glee.php)

don’t offer already?

If you are doing this to learn, then yeah, those functions
are working on most systems.


Paulo

On Fri, Aug 7, 2009 at 6:20 PM, GMScribe <@GMScribe> wrote:

Hi guys,

I’m wanting to implement some form of automation in respect to openGL
extensions.

Could someone confirm if the following would work on most/all openGL
capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.

View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context: http://www.nabble.com/OpenGL-Extensions-tp24867770p24886278.html
Sent from the SDL mailing list archive at Nabble.com.

Sure, I’d be interested in seeing what you come up with. As you noted one
of the issues with providing something like GLEW is keeping it up to date as
the spec changes.

See ya!On Sun, Aug 9, 2009 at 4:29 AM, GMScribe <ali_lowe at sky.com> wrote:

I’m looking looking for code that is up to date. GLEW and GLEE seem to have
hit a road block at openGL 3.0. I’ve checked the SVNs and these are also
lacking full support.

After looking at the code I’ve also come to the conclusion that updating
them would be a pain in the ass as how they’re written is a little all over
the place.

I’m considering, and yes partly to teach myself more about the basics of
openGL that aren’t usually exposed to me (I’ve used GLEW in the past), to
create similar code based on SDL’s existing functions like the one listed
so
that I can create a maintainable system that shares SDL’s portability
rather
than needing a slew of workarounds.

I’m also interested to see if people would like this feature as core to
SDL.
As Sam mentioned in a previous post, the concept of SDL is to make a
context
and get out the way so that people can use whatever extensions they like,
however, the biggest pain in the ass is that anyone using openGL above 1.1
has a load of core extensions to load and possibly some none core too,
ultimately leading to most of them needing GLEW etc as a necessity. If it’s
a necessity, why not provide it from the point of context creation?
Possibly
as an optional flag or an extra function not requiring the including of an
extra API.

One other consideration was that now gl3.h exists, we may see some
compatability issues from users mixing future version of GLEW/GLee and
SDL_opengl.h etc so I’m wanting to pre-empt this if possible by having
complete control over gl.h/gl3.h includes. Just another matter to consider.

Many thanks,

Paulo Pinto wrote:

Hi,

what would your automation offer that

GLEW (http://glew.sourceforge.net/) and
GLEE (http://elf-stone.com/glee.php)

don’t offer already?

If you are doing this to learn, then yeah, those functions
are working on most systems.


Paulo

On Fri, Aug 7, 2009 at 6:20 PM, GMScribe <ali_lowe at sky.com> wrote:

Hi guys,

I’m wanting to implement some form of automation in respect to openGL
extensions.

Could someone confirm if the following would work on most/all openGL
capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.

View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24886278.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Well I’m almost at the end of my little journey! However I’ve ran into a
final snag which is that I have no experience implementing a directly
accessable global variable in SDL, I have in SDL_opengl.h:

extern DECLSPEC SDL_GLProcsContext *sdlGlProcsContext;

In SDL_opengl.c (which I’ve added to my project, I’m using VC2008 btw) I
have:

SDL_GLProcsContext *sdlGlProcsContext;

My extern DECLSPEC functions are working ok however the above is causing
linker errors. Is there a special manner to expose variables in the SDL
library? This is of course required as a pointer for the openGL function
calls.

Many thanks.

Sam Lantinga-4 wrote:>

Sure, I’d be interested in seeing what you come up with. As you noted one
of the issues with providing something like GLEW is keeping it up to date
as
the spec changes.

See ya!

On Sun, Aug 9, 2009 at 4:29 AM, GMScribe <@GMScribe> wrote:

I’m looking looking for code that is up to date. GLEW and GLEE seem to
have
hit a road block at openGL 3.0. I’ve checked the SVNs and these are also
lacking full support.

After looking at the code I’ve also come to the conclusion that updating
them would be a pain in the ass as how they’re written is a little all
over
the place.

I’m considering, and yes partly to teach myself more about the basics of
openGL that aren’t usually exposed to me (I’ve used GLEW in the past), to
create similar code based on SDL’s existing functions like the one listed
so
that I can create a maintainable system that shares SDL’s portability
rather
than needing a slew of workarounds.

I’m also interested to see if people would like this feature as core to
SDL.
As Sam mentioned in a previous post, the concept of SDL is to make a
context
and get out the way so that people can use whatever extensions they like,
however, the biggest pain in the ass is that anyone using openGL above
1.1
has a load of core extensions to load and possibly some none core too,
ultimately leading to most of them needing GLEW etc as a necessity. If
it’s
a necessity, why not provide it from the point of context creation?
Possibly
as an optional flag or an extra function not requiring the including of
an
extra API.

One other consideration was that now gl3.h exists, we may see some
compatability issues from users mixing future version of GLEW/GLee and
SDL_opengl.h etc so I’m wanting to pre-empt this if possible by having
complete control over gl.h/gl3.h includes. Just another matter to
consider.

Many thanks,

Paulo Pinto wrote:

Hi,

what would your automation offer that

GLEW (http://glew.sourceforge.net/) and
GLEE (http://elf-stone.com/glee.php)

don’t offer already?

If you are doing this to learn, then yeah, those functions
are working on most systems.


Paulo

On Fri, Aug 7, 2009 at 6:20 PM, GMScribe <@GMScribe> wrote:

Hi guys,

I’m wanting to implement some form of automation in respect to openGL
extensions.

Could someone confirm if the following would work on most/all openGL
capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.

View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24886278.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context: http://www.nabble.com/OpenGL-Extensions-tp24867770p24898970.html
Sent from the SDL mailing list archive at Nabble.com.

OK Guys,

It’s really early days but linked below is my first attempt at GLEW like
functionality for SDL.

I got around my linker issue with variables by passing it through a function
as you’ll see in the code. If anyone knows how to do this correctly please
mail me as I’d really like to know!

All the code is automatically generated (and thus easy to maintain), I
tested this using the gl2 test under Windows by replacing the SDL_opengl.h
file and adding SDL_opengl.c to the VC project. I did have to comment out
2-3 references to the in-progress gl renderer in sdl_video.c due to a
conflict where it’s trying to do some of the job that this new code now
handles. If we can get this code stable the conflict can simply be removed
from the gl renderer.

http://www.nabble.com/file/p24904488/SDL_opengl.h SDL_opengl.h
http://www.nabble.com/file/p24904488/SDL_opengl.cpp SDL_opengl.cpp

Many thanks to anyone who is willing to put aside some time and give this a
try or provide feedback.

Sam Lantinga-4 wrote:>

Sure, I’d be interested in seeing what you come up with. As you noted one
of the issues with providing something like GLEW is keeping it up to date
as
the spec changes.

See ya!

On Sun, Aug 9, 2009 at 4:29 AM, GMScribe <@GMScribe> wrote:

I’m looking looking for code that is up to date. GLEW and GLEE seem to
have
hit a road block at openGL 3.0. I’ve checked the SVNs and these are also
lacking full support.

After looking at the code I’ve also come to the conclusion that updating
them would be a pain in the ass as how they’re written is a little all
over
the place.

I’m considering, and yes partly to teach myself more about the basics of
openGL that aren’t usually exposed to me (I’ve used GLEW in the past), to
create similar code based on SDL’s existing functions like the one listed
so
that I can create a maintainable system that shares SDL’s portability
rather
than needing a slew of workarounds.

I’m also interested to see if people would like this feature as core to
SDL.
As Sam mentioned in a previous post, the concept of SDL is to make a
context
and get out the way so that people can use whatever extensions they like,
however, the biggest pain in the ass is that anyone using openGL above
1.1
has a load of core extensions to load and possibly some none core too,
ultimately leading to most of them needing GLEW etc as a necessity. If
it’s
a necessity, why not provide it from the point of context creation?
Possibly
as an optional flag or an extra function not requiring the including of
an
extra API.

One other consideration was that now gl3.h exists, we may see some
compatability issues from users mixing future version of GLEW/GLee and
SDL_opengl.h etc so I’m wanting to pre-empt this if possible by having
complete control over gl.h/gl3.h includes. Just another matter to
consider.

Many thanks,

Paulo Pinto wrote:

Hi,

what would your automation offer that

GLEW (http://glew.sourceforge.net/) and
GLEE (http://elf-stone.com/glee.php)

don’t offer already?

If you are doing this to learn, then yeah, those functions
are working on most systems.


Paulo

On Fri, Aug 7, 2009 at 6:20 PM, GMScribe <@GMScribe> wrote:

Hi guys,

I’m wanting to implement some form of automation in respect to openGL
extensions.

Could someone confirm if the following would work on most/all openGL
capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.

View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24886278.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context: http://www.nabble.com/OpenGL-Extensions-tp24867770p24904488.html
Sent from the SDL mailing list archive at Nabble.com.

My apologies,

I’ve linked the wrong files, please find the correct files below:
http://www.nabble.com/file/p24904606/SDL_opengl.h SDL_opengl.h
http://www.nabble.com/file/p24904606/SDL_opengl.c SDL_opengl.c

The 3 functions are:

SDL_GLProcsContext *SDLCALL SDL_GL_GetCurrentProcsContext();
void SDL_GL_SwapProcsContext( SDL_GLProcsContext *context );
void SDL_GL_LoadProcs( SDL_GLProcsContext *context, SDL_bool
enableDepreciated, SDL_bool enableExtensions );

The first function is my workaround for direct variable access, the second
function may be used to swap between contexts if you require more than one,
passing a null/0 will use the default context. The third function is used to
initialise a context and must be ran before attempting to use any opengl
functions, again passing a null context will cause the default context to be
used.

Many thanks.

GMScribe wrote:>

OK Guys,

It’s really early days but linked below is my first attempt at GLEW like
functionality for SDL.

I got around my linker issue with variables by passing it through a
function as you’ll see in the code. If anyone knows how to do this
correctly please mail me as I’d really like to know!

All the code is automatically generated (and thus easy to maintain), I
tested this using the gl2 test under Windows by replacing the SDL_opengl.h
file and adding SDL_opengl.c to the VC project. I did have to comment out
2-3 references to the in-progress gl renderer in sdl_video.c due to a
conflict where it’s trying to do some of the job that this new code now
handles. If we can get this code stable the conflict can simply be removed
from the gl renderer.

http://www.nabble.com/file/p24904488/SDL_opengl.h SDL_opengl.h
http://www.nabble.com/file/p24904488/SDL_opengl.cpp SDL_opengl.cpp

Many thanks to anyone who is willing to put aside some time and give this
a try or provide feedback.

Sam Lantinga-4 wrote:

Sure, I’d be interested in seeing what you come up with. As you noted
one
of the issues with providing something like GLEW is keeping it up to date
as
the spec changes.

See ya!

On Sun, Aug 9, 2009 at 4:29 AM, GMScribe <@GMScribe> wrote:

I’m looking looking for code that is up to date. GLEW and GLEE seem to
have
hit a road block at openGL 3.0. I’ve checked the SVNs and these are also
lacking full support.

After looking at the code I’ve also come to the conclusion that updating
them would be a pain in the ass as how they’re written is a little all
over
the place.

I’m considering, and yes partly to teach myself more about the basics of
openGL that aren’t usually exposed to me (I’ve used GLEW in the past),
to
create similar code based on SDL’s existing functions like the one
listed
so
that I can create a maintainable system that shares SDL’s portability
rather
than needing a slew of workarounds.

I’m also interested to see if people would like this feature as core to
SDL.
As Sam mentioned in a previous post, the concept of SDL is to make a
context
and get out the way so that people can use whatever extensions they
like,
however, the biggest pain in the ass is that anyone using openGL above
1.1
has a load of core extensions to load and possibly some none core too,
ultimately leading to most of them needing GLEW etc as a necessity. If
it’s
a necessity, why not provide it from the point of context creation?
Possibly
as an optional flag or an extra function not requiring the including of
an
extra API.

One other consideration was that now gl3.h exists, we may see some
compatability issues from users mixing future version of GLEW/GLee and
SDL_opengl.h etc so I’m wanting to pre-empt this if possible by having
complete control over gl.h/gl3.h includes. Just another matter to
consider.

Many thanks,

Paulo Pinto wrote:

Hi,

what would your automation offer that

GLEW (http://glew.sourceforge.net/) and
GLEE (http://elf-stone.com/glee.php)

don’t offer already?

If you are doing this to learn, then yeah, those functions
are working on most systems.


Paulo

On Fri, Aug 7, 2009 at 6:20 PM, GMScribe <@GMScribe> wrote:

Hi guys,

I’m wanting to implement some form of automation in respect to openGL
extensions.

Could someone confirm if the following would work on most/all openGL
capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.

View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24886278.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context: http://www.nabble.com/OpenGL-Extensions-tp24867770p24904606.html
Sent from the SDL mailing list archive at Nabble.com.

I’m also interested in integrating these features into context creation to
hide most of the work from the end user, however, attempts to include
SDL_opengl.h in SDL_sysvideo.h cause a slew of errors and I’m struggling to
find the origin, any help would be greatly appreciated. Essentially all we
need to is place an instance of the structure holding opengl function
pointers into the glconfig structure, add initialisation code in context
creation and context swapping support.

Many thanks.

GMScribe wrote:>

My apologies,

I’ve linked the wrong files, please find the correct files below:
http://www.nabble.com/file/p24904606/SDL_opengl.h SDL_opengl.h
http://www.nabble.com/file/p24904606/SDL_opengl.c SDL_opengl.c

The 3 functions are:

SDL_GLProcsContext *SDLCALL SDL_GL_GetCurrentProcsContext();
void SDL_GL_SwapProcsContext( SDL_GLProcsContext *context );
void SDL_GL_LoadProcs( SDL_GLProcsContext *context, SDL_bool
enableDepreciated, SDL_bool enableExtensions );

The first function is my workaround for direct variable access, the second
function may be used to swap between contexts if you require more than
one, passing a null/0 will use the default context. The third function is
used to initialise a context and must be ran before attempting to use any
opengl functions, again passing a null context will cause the default
context to be used.

Many thanks.

GMScribe wrote:

OK Guys,

It’s really early days but linked below is my first attempt at GLEW like
functionality for SDL.

I got around my linker issue with variables by passing it through a
function as you’ll see in the code. If anyone knows how to do this
correctly please mail me as I’d really like to know!

All the code is automatically generated (and thus easy to maintain), I
tested this using the gl2 test under Windows by replacing the
SDL_opengl.h file and adding SDL_opengl.c to the VC project. I did have
to comment out 2-3 references to the in-progress gl renderer in
sdl_video.c due to a conflict where it’s trying to do some of the job
that this new code now handles. If we can get this code stable the
conflict can simply be removed from the gl renderer.

http://www.nabble.com/file/p24904488/SDL_opengl.h SDL_opengl.h
http://www.nabble.com/file/p24904488/SDL_opengl.cpp SDL_opengl.cpp

Many thanks to anyone who is willing to put aside some time and give this
a try or provide feedback.

Sam Lantinga-4 wrote:

Sure, I’d be interested in seeing what you come up with. As you noted
one
of the issues with providing something like GLEW is keeping it up to
date as
the spec changes.

See ya!

On Sun, Aug 9, 2009 at 4:29 AM, GMScribe <@GMScribe> wrote:

I’m looking looking for code that is up to date. GLEW and GLEE seem to
have
hit a road block at openGL 3.0. I’ve checked the SVNs and these are
also
lacking full support.

After looking at the code I’ve also come to the conclusion that
updating
them would be a pain in the ass as how they’re written is a little all
over
the place.

I’m considering, and yes partly to teach myself more about the basics
of
openGL that aren’t usually exposed to me (I’ve used GLEW in the past),
to
create similar code based on SDL’s existing functions like the one
listed
so
that I can create a maintainable system that shares SDL’s portability
rather
than needing a slew of workarounds.

I’m also interested to see if people would like this feature as core to
SDL.
As Sam mentioned in a previous post, the concept of SDL is to make a
context
and get out the way so that people can use whatever extensions they
like,
however, the biggest pain in the ass is that anyone using openGL above
1.1
has a load of core extensions to load and possibly some none core too,
ultimately leading to most of them needing GLEW etc as a necessity. If
it’s
a necessity, why not provide it from the point of context creation?
Possibly
as an optional flag or an extra function not requiring the including of
an
extra API.

One other consideration was that now gl3.h exists, we may see some
compatability issues from users mixing future version of GLEW/GLee and
SDL_opengl.h etc so I’m wanting to pre-empt this if possible by having
complete control over gl.h/gl3.h includes. Just another matter to
consider.

Many thanks,

Paulo Pinto wrote:

Hi,

what would your automation offer that

GLEW (http://glew.sourceforge.net/) and
GLEE (http://elf-stone.com/glee.php)

don’t offer already?

If you are doing this to learn, then yeah, those functions
are working on most systems.


Paulo

On Fri, Aug 7, 2009 at 6:20 PM, GMScribe <@GMScribe> wrote:

Hi guys,

I’m wanting to implement some form of automation in respect to
openGL

extensions.

Could someone confirm if the following would work on most/all openGL
capable
systems?
http://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress
ttp://sdl.beuc.net/sdl.wiki/SDL_GL_GetProcAddress

If not, what kind of modifications may be involved?

Many thanks.

View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24867770.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context:
http://www.nabble.com/OpenGL-Extensions-tp24867770p24886278.html
Sent from the SDL mailing list archive at Nabble.com.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context: http://www.nabble.com/OpenGL-Extensions-tp24867770p24917069.html
Sent from the SDL mailing list archive at Nabble.com.

ultimately leading to most of them needing GLEW etc as a necessity. If it’s

I’m not sure why GLEW is a necessity…I’ve always thought of it as
completely unnecessary.

I mean, doing it yourself means juggling a few checks for extension
strings, versions, and function lookups, but I would not consider it to
be a particularly complex endeavor.

The hard part–context creation and function lookup–is already handled
by SDL (but yeah, we do need to get GL3 context creation in there…).

–ryan.

I guess it depends on how many extensions you’re wanting to use. I mean as
openGL moves along, more and more extentions are integrated into core,
increasing the likelyhood that you’re going to have to activate more. I
think it just keeps clutter down and lets coders new to SDL or who wish to
start using openGL instantly for a quick tech demo etc jump right in there;
but I do understand where you’re coming from, but if it’s optional I guess
there’s no harm either way.

I submitted a patch for GL3.2 context creation about a week ago, still
waiting for it to be looked at. I’m currently looking at integrating the
extension code into context creation in order to hide it entirely from the
end user however I’m forced to include windows.h too early on in the SDL
compiling process and some functions aren’t liking it so I’m trying to find
a way to keep windows.h from being included when it shouldn’t be.

Ryan C. Gordon-2 wrote:>

ultimately leading to most of them needing GLEW etc as a necessity. If
it’s

I’m not sure why GLEW is a necessity…I’ve always thought of it as
completely unnecessary.

I mean, doing it yourself means juggling a few checks for extension
strings, versions, and function lookups, but I would not consider it to
be a particularly complex endeavor.

The hard part–context creation and function lookup–is already handled
by SDL (but yeah, we do need to get GL3 context creation in there…).

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


View this message in context: http://www.nabble.com/OpenGL-Extensions-tp24867770p24955663.html
Sent from the SDL mailing list archive at Nabble.com.