SDL/OpenGL and Portability

I am currently teaching an undergraduate course on free game
development. I wanted all the projects to be totally portable, so I
chose SDL/OpenGL to be the target platform. There have been a few
"hiccups", but only one major problem. While sdl-config can make sure a
single makefile can compile SDL apps on any of the platforms we use, and
SDL_opengl.h makes the code able to be completely portable, it does
nothing to help with linking the OpenGL libraries. In most systems this
would be -lGL and -lGLU, but in Windows this is -lopengl32 and -lglu32,
while in MacOS-X this is -framework OpenGL, etc…

Is there a standard way to handle this? If not, is there any reason
sdl-config can’t get something like “–libs-gl” and "–libs-glu"
options? That way each Makefile could just use sdl-config --libs-glu
and no separate rules will be needed for different platforms.

What do you all think about this? Is there a better way I am missing?–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050331/9e17a2f9/attachment.pgp

[…]

SDL_opengl.h makes the code able to be completely portable, it does
nothing to help with linking the OpenGL libraries. In most systems
this would be -lGL and -lGLU, but in Windows this is -lopengl32 and
-lglu32, while in MacOS-X this is -framework OpenGL, etc…

Is there a standard way to handle this? If not, is there any reason
sdl-config can’t get something like “–libs-gl” and "–libs-glu"
options? That way each Makefile could just use sdl-config
–libs-glu and no separate rules will be needed for different
platforms.

What do you all think about this? Is there a better way I am
missing?

I think the primary reason is that the preferred approach is usually
to load the OpenGL library “manually”, at run time. That allows your
application to load and start even if there is no OpenGL support on
the system, so you can use some other API, or give the user a
sensible error message. (Note: There may not even be an OpenGL
library at all!) This approach also makes it possible to add an
option to let the user decide what OpenGL library/driver to use.

If you’re loading OpenGL at run time, all you need at build time is
the OpenGL header. The rest is handled if/when your application
actually tries to fire up OpenGL.

SDL has portable support for doing this;
SDL_GL_LoadLibrary();
SDL_GL_GetProcAddress();

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Thursday 31 March 2005 18.11, Steaphan Greene wrote:

I see. Thanks for the quick response.

Is there any interest in being able to automatically link the shared gl
library at runtime? It makes the projects simpler (no gl function
pointers and such) and all of the target platforms have opengl support
libraries.

Otherwise, is there already an encapsulation of OpenGL around somewhere
which works with SDL and implements auto-detection/loading of the
library and auto-linking stubs to the gl functions, or is that something
else I’m gonna have to write? As it seems to me now, I’d still have the
problem of needing to figure out the correct path of the gl library on
each system, just the problem moves to runtime instead of compile-time.
Is there some portable way to detect these?On Thu, Mar 31, 2005 at 07:02:55PM +0200, David Olofson wrote:

On Thursday 31 March 2005 18.11, Steaphan Greene wrote:
[…]

SDL_opengl.h makes the code able to be completely portable, it does
nothing to help with linking the OpenGL libraries. In most systems
this would be -lGL and -lGLU, but in Windows this is -lopengl32 and
-lglu32, while in MacOS-X this is -framework OpenGL, etc…

Is there a standard way to handle this?
[…]

I think the primary reason is that the preferred approach is usually
to load the OpenGL library “manually”, at run time. That allows your
application to load and start even if there is no OpenGL support on
the system, so you can use some other API, or give the user a
sensible error message. (Note: There may not even be an OpenGL
library at all!) This approach also makes it possible to add an
option to let the user decide what OpenGL library/driver to use.

If you’re loading OpenGL at run time, all you need at build time is
the OpenGL header. The rest is handled if/when your application
actually tries to fire up OpenGL.

SDL has portable support for doing this;
SDL_GL_LoadLibrary();
SDL_GL_GetProcAddress();


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050331/48fa741c/attachment.pgp

I am currently teaching an undergraduate course on free game
development. I wanted all the projects to be totally portable, so I
chose SDL/OpenGL to be the target platform. There have been a few
"hiccups", but only one major problem. While sdl-config can make sure a
single makefile can compile SDL apps on any of the platforms we use, and
SDL_opengl.h makes the code able to be completely portable, it does
nothing to help with linking the OpenGL libraries. In most systems this
would be -lGL and -lGLU, but in Windows this is -lopengl32 and -lglu32,
while in MacOS-X this is -framework OpenGL, etc…

Is there a standard way to handle this? If not, is there any reason
sdl-config can’t get something like “–libs-gl” and "–libs-glu"
options? That way each Makefile could just use sdl-config --libs-glu
and no separate rules will be needed for different platforms.

What do you all think about this? Is there a better way I am missing?

I also teach a game programming class and have never run into this
problem :-). The reason I’ve never seen it is that there is a lot of
difference between being source level portable and being portable all
the way down to the development environment.

The development environments on the Mac, Windows, and Linux/UNIX are so
different that nobody seems to expect the make files to work across
different platforms. On Windows, my students generally need to be able
to configure Visual C/C++ to find the right headers and link with the
right libraries. On Linux they are usually using make files and I can
tell them how to set them up. On the Mac, well I have had students who
used Macs and wrote great games but they don’t ask me how to set up
their development environment.

If you insist on using make files and command line tools on all
platforms, then I guess the right way to do it is using the
standard ./autogen;./configure;make tools so that the make files are
autogened and tuned for each platform. That is, use the same tool chain
that SDL and most of the rest of the open source world use to make
makefile portable.

	Bob Pendleton

P.S.

Don’t worry about loading OGL at run time. Just link with the dynamic
libraries and you will get the right OGL for the platform linked in at
run time. The SDL APIs for dynamic loading are useful for testing a new
or alternative OGL libs but aren’t (in my experience) needed in most
cases.On Thu, 2005-03-31 at 11:11 -0500, Steaphan Greene wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[…]

Is there any interest in being able to automatically link the shared
gl library at runtime? It makes the projects simpler (no gl
function pointers and such) and all of the target platforms have
opengl support libraries.

Well, I used to do that before, and I have GNU Autoconf scripts to
take care of the details of linking - statically or dynamically -
with OpenGL.

However, the problem is that dynamic linking means the application
won’t even load if there’s no OpenGL lib. (That’s why there are two
binaries in current (old) Kobo Deluxe Win32 packages; the one with
OpenGL support won’t even load without an opengl32.dll.)

Static linking is pretty much out, unless you count on all users
building from source, as some (most?) platforms have driver specific
GL libs.

So, I’d recommend the third kind of “linking”; load it manually.

Otherwise, is there already an encapsulation of OpenGL around
somewhere which works with SDL and implements auto-detection/loading
of the library and auto-linking stubs to the gl functions, or is
that something else I’m gonna have to write?

There are various OpenGL helpers around, but I don’t have much
experience with them… Just grabbing the functions isn’t that much
work anyway. Grabbing only the ones you actually use could be nice if
you’re using functions that may not be provided by all drivers - but
then again, a helper library could just wire the stubs to some
function that grabs the real function if/when it’s hit the first
time.

As it seems to me now, I’d still have the problem of needing to
figure out the correct path of the gl library on each system, just
the problem moves to runtime instead of compile-time.
Is there some portable way to detect these?

SDL does that. Unless you want to load a specific, nonstandard OpenGL
driver, just pass NULL to SDL_GL_LoadLibrary(), and it’ll load the
standard library on whatever platform you’re on.

This seems to be undocumented, though… “It Works Here™” :wink: IIRC,
I actually found out about this feature while messing with the glSDL
backend, and converting glSDL/wrapper to run time OpenGL loading. I
think I found default library paths for all platforms with OpenGL
support, but I’m not 100% sure…

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Thursday 31 March 2005 20.35, Steaphan Greene wrote:

Well, I used to do that before, and I have GNU Autoconf scripts to
take care of the details of linking - statically or dynamically -
with OpenGL.

Yeah, I was hoping to avoid this. The addition of --libs-gl and
–libs-glu to sdl-config would solve the problem for my class needs.

However, the problem is that dynamic linking means the application
won’t even load if there’s no OpenGL lib. (That’s why there are two
binaries in current (old) Kobo Deluxe Win32 packages; the one with
OpenGL support won’t even load without an opengl32.dll.)

Right, but it’s not big deal to simply state that the game requires
opengl installed and setup. Most of the games would be completely
unplayable with software emulation anyway.

Static linking is pretty much out, unless you count on all users
building from source, as some (most?) platforms have driver specific
GL libs.

No, I wouldn’t do that.

There are various OpenGL helpers around, but I don’t have much
experience with them… Just grabbing the functions isn’t that much
work anyway. Grabbing only the ones you actually use could be nice if
you’re using functions that may not be provided by all drivers - but
then again, a helper library could just wire the stubs to some
function that grabs the real function if/when it’s hit the first
time.

That’s what I’m looking for - prefereably one that remaps normal gl
named functions to this kind of stubs, so normal opengl code from
whatever source will run it it without modification.

SDL does that. Unless you want to load a specific, nonstandard OpenGL
driver, just pass NULL to SDL_GL_LoadLibrary(), and it’ll load the
standard library on whatever platform you’re on.

This seems to be undocumented, though… “It Works Here™” :wink: IIRC,
I actually found out about this feature while messing with the glSDL
backend, and converting glSDL/wrapper to run time OpenGL loading. I
think I found default library paths for all platforms with OpenGL
support, but I’m not 100% sure…

Ahh. This doesn’t seem to be in any of the docs I’ve see either. If
this really is a supported feature, this becomes a bit more possible.
Anyone have an official word on this?On Thu, Mar 31, 2005 at 10:11:14PM +0200, David Olofson wrote:


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050331/b16e2fd8/attachment.pgp

I also teach a game programming class and have never run into this
problem :-). The reason I’ve never seen it is that there is a lot of
difference between being source level portable and being portable all
the way down to the development environment.

Of course.

The development environments on the Mac, Windows, and Linux/UNIX are
so different that nobody seems to expect the make files to work across
different platforms.

IMHO, they SHOULD expect this. Especially with something like SDL. I
should be able to just require SDL/OpenGL, gcc-3.x, and gnu make, and
the platform should then be irrelevant. Then students can develop on
any platform they choose, and tas, instructors, and others can compile
their programs anywhere right out of the box.

On Windows, my students generally need to be able to configure Visual
C/C++ to find the right headers and link with the right libraries. On
Linux they are usually using make files and I can tell them how to set
them up. On the Mac, well I have had students who used Macs and wrote
great games but they don’t ask me how to set up their development
environment.

If you insist on using make files and command line tools on all
platforms, then I guess the right way to do it is using the standard
./autogen;./configure;make tools so that the make files are autogened
and tuned for each platform. That is, use the same tool chain that SDL
and most of the rest of the open source world use to make makefile
portable.

…which I was hoping to avoid. I don’t know why, but I’ve had more
obscure problems with auto* than with any other aspect of the various
projects I’ve maintained.On Thu, Mar 31, 2005 at 01:49:27PM -0600, Bob Pendleton wrote:


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050331/e3cec256/attachment.pgp

This isn’t really an option. Since I’m supporting not just one single
app, but a class with muny different apps, the library would have to
provide any and everything GL and GLU provide. I could do this, but I’m
not looking forward to the amount of work it would require. So, I was
hopeing someone out there had done it already. Anyone?On Thu, Mar 31, 2005 at 10:11:14PM +0200, David Olofson wrote:

There are various OpenGL helpers around, but I don’t have much
experience with them… Just grabbing the functions isn’t that much
work anyway.


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050331/0ff77114/attachment.pgp

Steaphan Greene wrote:

Well, I used to do that before, and I have GNU Autoconf scripts to
take care of the details of linking - statically or dynamically -
with OpenGL.

Yeah, I was hoping to avoid this. The addition of --libs-gl and
–libs-glu to sdl-config would solve the problem for my class needs.

It’s been discussed some time ago, and I think everyone agrees that
–libs-gl(u) is a good idea.
It’s just that nobody implemented it.

However, the problem is that dynamic linking means the application
won’t even load if there’s no OpenGL lib. (That’s why there are two
binaries in current (old) Kobo Deluxe Win32 packages; the one with
OpenGL support won’t even load without an opengl32.dll.)

Right, but it’s not big deal to simply state that the game requires
opengl installed and setup. Most of the games would be completely
unplayable with software emulation anyway.

Software emulation is a libGL.so already. What won’t work is the lack of
a libGL. i.e. systems that don’t have libGL or don’t have it properly
installed.
That’s nice to have so that :

  • you can warn the user “OpenGL not installed”
  • if you’re using OpenGL for 2d, you can fallback to OpenGL-less
    operation and not bother the user

SDL does that. Unless you want to load a specific, nonstandard OpenGL
driver, just pass NULL to SDL_GL_LoadLibrary(), and it’ll load the
standard library on whatever platform you’re on.

This seems to be undocumented, though… “It Works Here™” :wink: IIRC,
I actually found out about this feature while messing with the glSDL
backend, and converting glSDL/wrapper to run time OpenGL loading. I
think I found default library paths for all platforms with OpenGL
support, but I’m not 100% sure…

Ahh. This doesn’t seem to be in any of the docs I’ve see either. If
this really is a supported feature, this becomes a bit more possible.
Anyone have an official word on this?

Actually, any parameter to SDL_GL_LoadLibrary that fails to load
correctly will be replaced by a default path.
But IIRC this won’t save you on all situations (especially with the x11
SDL backend which can work on so many different platforms).

To answer your original question, I don’t think it’s worth the trouble
for a class project to have dynamic OpenGL loading. Just doing dynamic
linking will be fine, and minor modifications to the Makefile are enough
to sort it out.

Stephane>On Thu, Mar 31, 2005 at 10:11:14PM +0200, David Olofson wrote:

Steaphan Greene wrote:

SDL does that. Unless you want to load a specific, nonstandard OpenGL
driver, just pass NULL to SDL_GL_LoadLibrary(), and it’ll load the
standard library on whatever platform you’re on.
[…]

Ahh. This doesn’t seem to be in any of the docs I’ve see either. If
this really is a supported feature, this becomes a bit more possible.
Anyone have an official word on this?

Actually, any parameter to SDL_GL_LoadLibrary that fails to load
correctly will be replaced by a default path.

Umm, no.
An invalid path results in an error “Could not load OpenGL library”.

On X11, a NULL pointer means loading pointers from the application if linked
with libGL, otherwise use libGL.so(.1)

On Win32, a NULL pointer means loading opengl32.dll.

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Thursday 31 March 2005 23:18, Stephane Marchesin wrote:

Well, I used to do that before, and I have GNU Autoconf scripts to
take care of the details of linking - statically or dynamically -
with OpenGL.

Yeah, I was hoping to avoid this. The addition of --libs-gl and
–libs-glu to sdl-config would solve the problem for my class needs.

Yeah, might be handy. I don’t really care much for Autotools, BTW…
It’s huge, messy, slow and doesn’t really do the job too well anyway.
It seems to be the de-facto standard, and I’ve done a few projects
with it now; that’s probably the main reasons why I’m still using it.

However, the problem is that dynamic linking means the application
won’t even load if there’s no OpenGL lib. (That’s why there are
two
binaries in current (old) Kobo Deluxe Win32 packages; the one with
OpenGL support won’t even load without an opengl32.dll.)

Right, but it’s not big deal to simply state that the game requires
opengl installed and setup. Most of the games would be completely
unplayable with software emulation anyway.

Right; Kobo Deluxe and other 2D games using OpenGL, that are still
actually playable without OpenGL, are a bit of a special case.

Either way, the reason I included the non-OpenGL exe was that some
Windows machines I tested on plain didn’t have any traces of OpenGL
whatsoever, and thus refused to load the kobogl.exe. IIRC, those were
Win95 machines. WinNT 4.0, Win95 and later should at least have the
s/w implementation installed. Not much of an issue, I guess…

As to Windows-only video cards with Direct3D/DirectGraphics drivers
only (there are a few of those, apparently); I guess you could still
link with OpenGL and have the s/w fallback save your *ss even with
those cards. (Provided you support Direct3D as well, of course.)

[…passing NULL to SDL_GL_LoadLibrary()…]

Ahh. This doesn’t seem to be in any of the docs I’ve see either.
If this really is a supported feature, this becomes a bit more
possible. Anyone have an official word on this?

I’d like to know too, because the last few “unofficial” versions of
glSDL use that “feature”. :smiley:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
http://olofson.nethttp://www.reologica.se —On Thursday 31 March 2005 22.53, Steaphan Greene wrote:

On Thu, Mar 31, 2005 at 10:11:14PM +0200, David Olofson wrote:

I am currently teaching an undergraduate course on free game
development. I wanted all the projects to be totally portable, so I
chose SDL/OpenGL to be the target platform. There have been a few
"hiccups", but only one major problem. While sdl-config can make sure a
single makefile can compile SDL apps on any of the platforms we use, and
SDL_opengl.h makes the code able to be completely portable, it does
nothing to help with linking the OpenGL libraries. In most systems this
would be -lGL and -lGLU, but in Windows this is -lopengl32 and -lglu32,
while in MacOS-X this is -framework OpenGL, etc…

Is there a standard way to handle this? If not, is there any reason
sdl-config can’t get something like “–libs-gl” and "–libs-glu"
options? That way each Makefile could just use sdl-config --libs-glu
and no separate rules will be needed for different platforms.

What do you all think about this? Is there a better way I am missing?

My take on this is that all the development environments are just too
different for SDL to handle all this. On the Mac alone, there are two
totally different ways to reach SDL (via Frameworks or via more
traditional Unix styles.) Throw in Visual Studio into the mix, and
you have pretty much no common ground to work with.

My solution is to use a a project/build generator. I discovered I was
too stupid to figure out autoconf/automake, and it really doesn’t
address anything outside the Unix domain, so I don’t use those.

But there are two I know of I think that are worth advertising. The
first is called CMake. CMake can generate native projects for many
different compilers (Visual Studio 6,7,7.1, Borland, Unix Makefiles,
KDevelop, (Xcode in development)). You describe your build process in
a text file (script) and CMake will generate a project based on it.
It’s much higher level than a Makefile which makes it nice. They also
provide prewritten modules for popular libraries that handle the
detection of those libraries and set the path locations. SDL and
OpenGL are among those modules. And it’s pretty easy to copy and paste
their modules to make new ones to test for things like OpenAL or
whatever. I use CMake for many of my projects now.

The other one is called SCons. SCons is similar to CMake but the
scripting language is all built on Python. I’ve never used this one,
but I hear good things about it. I don’t know Python (Perl background)
so that wasn’t an advantage for me. One thing I didn’t like so much
from the examples I saw was that you spend a little bit of time
massaging your data entry to satisfy the Python lexer and type
conventions. I think CMake was a little more straightforward. I also
didn’t think I needed as much power as Python provides. But if you’re
a Python person, you’ll probably love SCons. Even if you’re not, it’s
still worth checking out.

Both projects are open source.

-Eric> From: Steaphan Greene

Hi, Autotools are fine in many projects, but you should be aware that there is “scons”, I suggest its use because it’s sympler, but it needs python for being installed. Scons claims to be more cross-platform, compatible/native with windows than autotools are. (need cygwin I guess.) As for packaging may I suggest http://www.autopackage.org/ for building linux binaries compatible with many distros? As a novice linux user (never packaged anything with it) it was a breeze to install software with it!---------------------------------
Nuovo Yahoo! Messenger E’ molto pi? divertente: Audibles, Avatar, Webcam, Giochi, Rubrica
Scaricalo ora!

I also teach a game programming class and have never run into this
problem :-). The reason I’ve never seen it is that there is a lot of
difference between being source level portable and being portable all
the way down to the development environment.

Of course.

The development environments on the Mac, Windows, and Linux/UNIX are
so different that nobody seems to expect the make files to work across
different platforms.

IMHO, they SHOULD expect this.

Why? They are different platforms with different tool chains from
different vendors.

Especially with something like SDL. I
should be able to just require SDL/OpenGL, gcc-3.x, and gnu make, and
the platform should then be irrelevant.

Humm… Yeah. Well, it isn’t and there is very little that SDL can do
about it.

The thing that surprises me the most is that you can require students to
use gcc and gnu make on Windows and on the Mac. If I tried to do that I
wouldn’t have any students. Seriously, if I told students who are Mac
and Windows users that they couldn’t use their favorite IDEs most would
walk out. By the end of the class their exposure to SDL and OpenGL leads
them to be more accepting of non-Microsoft and non-Apple ways of doing
things. But, I have lost students because I was using SDL and OpenGL.
Many many people are absolutely convinced that it isn’t game programming
if it isn’t using DirectX on Windows.

…which I was hoping to avoid. I don’t know why, but I’ve had more
obscure problems with auto* than with any other aspect of the various
projects I’ve maintained.

Me too.

	Bob PendletonOn Thu, 2005-03-31 at 15:58 -0500, Steaphan Greene wrote:

On Thu, Mar 31, 2005 at 01:49:27PM -0600, Bob Pendleton wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Steaphan Greene wrote:> On Thu, Mar 31, 2005 at 10:11:14PM +0200, David Olofson wrote:

There are various OpenGL helpers around, but I don’t have much
experience with them… Just grabbing the functions isn’t that much
work anyway.

This isn’t really an option. Since I’m supporting not just one single
app, but a class with muny different apps, the library would have to
provide any and everything GL and GLU provide. I could do this, but I’m
not looking forward to the amount of work it would require. So, I was
hopeing someone out there had done it already. Anyone?

If you do choose to load OpenGL at runtime GLEW will do the grunt work
for you:

http://glew.sourceforge.net/

I haven’t used it myself, but it looks simple enough:

http://glew.sourceforge.net/basic.html


Jon

These pages make it seem (to me at least) that it just manages the
loading of opengl extensions, not the opengl lib itself. Is this not
the case?On Fri, Apr 01, 2005 at 10:23:34PM +0100, Jon Colverson wrote:

If you do choose to load OpenGL at runtime GLEW will do the grunt work
for you:

http://glew.sourceforge.net/

I haven’t used it myself, but it looks simple enough:

http://glew.sourceforge.net/basic.html


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050402/c163de82/attachment.pgp

The development environments on the Mac, Windows, and Linux/UNIX are
so different that nobody seems to expect the make files to work across
different platforms.

IMHO, they SHOULD expect this.

Why? They are different platforms with different tool chains from
different vendors.

Standards are a beautiful thing. Just because so few companies in our
industry use and follow them doesn’t mean they shouldn’t exist and
should not be followed.

The thing that surprises me the most is that you can require students to
use gcc and gnu make on Windows and on the Mac.

I don’t. They can use whatever environment they want. The just have to
be sure it DOES work with gcc on all these platforms and provide a
working Makefile. I provide a compiling environment in Linux that can
also cross compile for Windows for testing, but they can feel free to
use whatever environment they want, provided they can get SDL and
friends working with it on their own.

If I tried to do that I wouldn’t have any students. Seriously, if I
told students who are Mac and Windows users that they couldn’t use
their favorite IDEs most would walk out. By the end of the class their
exposure to SDL and OpenGL leads them to be more accepting of
non-Microsoft and non-Apple ways of doing things. But, I have lost
students because I was using SDL and OpenGL.

Sounds like you don’t have very interested students. :wink:

Many many people are absolutely convinced that it isn’t game
programming if it isn’t using DirectX on Windows.

And years before that people would have said that writing games for
personal computers was a waste of time. Again, just because people
aren’t doing something, doesn’t mean it’s not the right thing to do.

It’s important to note that I’m not teaching a game programming class,
I’m teaching an open game development class. There is a big difference.
The focus of my course is on the open development, not the games.On Fri, Apr 01, 2005 at 02:42:37PM -0600, Bob Pendleton wrote:


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050402/28e40417/attachment.pgp

Steaphan Greene wrote:> On Fri, Apr 01, 2005 at 10:23:34PM +0100, Jon Colverson wrote:

If you do choose to load OpenGL at runtime GLEW will do the grunt work
for you:

http://glew.sourceforge.net/

I haven’t used it myself, but it looks simple enough:

http://glew.sourceforge.net/basic.html

These pages make it seem (to me at least) that it just manages the
loading of opengl extensions, not the opengl lib itself. Is this not
the case?

Well, it doesn’t load the library (you’d need to use the apparently
undocumented SDL_GL_LoadLibrary(NULL) behaviour for that), but the GLEW
header does contain the names of the core OpenGL functions, and
glewInit() hooks those up to the loaded library. I guess I was a little
imprecise in my last post.


Jon

Ahh. Hadn’t seen that. I’ll look into that solution. Thanks.On Sun, Apr 03, 2005 at 05:16:28AM +0100, Jon Colverson wrote:

Well, it doesn’t load the library (you’d need to use the apparently
undocumented SDL_GL_LoadLibrary(NULL) behaviour for that), but the
GLEW header does contain the names of the core OpenGL functions, and
glewInit() hooks those up to the loaded library. I guess I was a
little imprecise in my last post.


Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050406/aed3d679/attachment.pgp