Fixing Win32 build with SCons

Thread Rating:

0 Vote(s) - 0 Average
1
2
3
4
5

Thread Modes

Fixing Win32 build with SCons

07-19-2007, 01:17 PM,

#36

thelusiv Offline

Administrator

Posts: 2,346
Threads: 223
Joined: Jun 2005

On Windows, the problem is that OpenGL headers and libraries available with the OS (or available at all) are all OpenGL 1.1. Other systems tend to have 1.3 or better. Of course MS is not interested in supporting OpenGL because they'd rather developers use their product (DirectX) anyway.

Thus, all the new GL capabilities are not in the headers/libs. It's possible to use GL extensions by doing some crazy stuff with function pointers but that quickly becomes messy, so it makes sense to hand that off to a library or class that can manage GL extensions. Rather than take the time to write our own class, it's much simpler to use GLEW which makes things even easier - it does some magic to make the regular extension function calls resolve to the proper place without having to get function pointers to locate them by. It also figures out which extensions and capabilities are available and sets up flags (much like Joe's CARDINFO class does) that the developer can use to detect what functionality is available.

Let me first say that Joe is the real GL expert here, not me. Here are my thoughts on the subject of using GLEW on all platforms.
Pros

GLEW is a mature library that provides all the functionality we need to evaluate the user's graphics card/drivers, and find extensions.
Using GLEW would make it almost unnecessary for us to maintain the CARDINFO class (or at least make the CARDINFO class much simpler).
It seems to work well and is available on all platforms.
It has been through lots of years of testing and is probably very stable and fast.
It may account for some special cases that we haven't thought of/shouldn't have to worry about.

Cons

It would take some work to modify the CARDINFO class or replace it with GLEW.
It is one more library required to compile/run the game.
We already have this functionality so it may not be all that beneficial.

Personally I think the best way to go would be to modify the CARDINFO class so that it uses GLEW to do all the work. This would be the simplest route as we wouldn't have to change all the existing references to the CARDINFO class, and having GLEW wrapped in our own class gives us the ability to add other functionality around it (for instance error checking/trapping). Thus we'd inherit the wisdom the GLEW project has accumulated over the years of development all at once. I think this would help VDrift better detect available extensions and capabilities on different graphics cards.

I'm really not sure if it would be any different from what we have now. But my hunch is that there are idiosyncrasies existing in different libraries/drivers that GLEW may do a better job at detecting and handling than we can, given the scope of our project.

I know Joe's take on this. Wink

But I think maybe at least we should look into the GLEW source and see if there's not more going on there than we think. If so I think it would be beneficial to use on all platforms, and I'd be willing to work on making this happen.

Thoughts?

Find