Fixing Win32 build with SCons

[joevenzon]

GLEW is useful in windows because it allows an easy way to use opengl extensions. It's not really needed for other platforms, because they have up-to-date opengl support, but it shouldn't hurt anything. It works for me on linux, anyway.

[rookie1]

If this is the case, can we wrap GLEW with #ifdef _WIN32 so that we have one less dependency libraries?

[joevenzon]

That's fine with me... so we'd need to do #ifdefs for the glew headers and some stuff in the scons files to only add the lib on windows, right?

[rookie1]

Correct me if I'm wrong, the only GLEW function currently used (besides glewInit()) is glewGetExtension("GL_ARB_multitexture"), which can be replaced by game.gfxcard.GetCapability(CARDINFOTYPE::MULTITEXTURE) as per Joe's previous post. If this is the case, we should be able to totally remove GLEW dependency. Or is there something I'm not aware in the Windows build process?

[abs1nth]

but...that would mean the effort to produce an universal binary framework for GLEW would have been unnecessary ;-|

[thelusiv]

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. 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?

[joevenzon]

*Using GLEW would make it almost unnecessary for us to maintain the CARDINFO class (or at least make the CARDINFO class much simpler).

This isn't true; the cardinfo class is necessary. There are 4 functions the cardinfo class provides. 1) The cardinfo class supplies an interface to the rest of the program to be able to get graphics card parameters. This allows all of the other classes to be dependent on CARDINFO rather than on GL or GLEW functions (this abstraction is nice, I think). 2) The cardinfo class has logic that will do things like, for example, check if all extensions are present (vertex programs, fragment programs, etc) to support shaders as we use them. The other classes can then just ask the cardinfo class if shaders are supported instead of having to manually check for all of the right extensions and settings each time. 3) The cardinfo also does more than track supported extensions; for example, it keeps track of how many texture units are supported, the maximum anisotropy level, etc. 4) The cardinfo class tells the user (currently gets printed on the console) what functionality the card does and does not support, out of the total list of functionality that VDrift cares about. Because of these reasons, getting rid of the CARDINFO class doesn't make sense.

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.

The CARDINFO class currently uses OpenGL to query what extensions are supported. GLEW has ways to query what extensions are supported, too. The end result is identical (there's no special logic in telling you whether or not an extension is supported or not -- it either is or it isn't, and it's determined by logic in the graphics card driver).

I'm totally baffled as to 1) what problem you think there is with the CARDINFO class and 2) what GLEW would bring to the table. I think you're vastly over-estimating the complexity of querying for extensions -- you just call a function, and the graphics card driver spits out a list of extensions it supports.

To really hammer all of this home, go open cardinfo.cpp. The ONLY call to OpenGL to check for extensions is line 8. I quote:

Code:

char * temp = (char *) glGetString(GL_EXTENSIONS);

Explain to me what the problem here is, and how using GLEW makes this better.

[joevenzon]

All of that said, if there's a reason to use GLEW for build process consistency, then that's a different argument entirely, and I don't really have an opinion (my point is that from a programming perspective, there is no reason to remove the CARDINFO class or change the CARDINFO class to use GLEW).

[rookie1]

Again correct me if I'm wrong . From what I see, the main benefit of GLEW is to provide the GL extension function headers, and a transparent way of calling those extension functions in Windows. Seems to me we don't need it for the other platforms.

[joevenzon]

From what I see, the main benefit of GLEW is to provide the GL extension function headers, and a transparent way of calling those extension functions in Windows.

Yes, that's exactly it. GLEW makes available all of the opengl functionality that your graphics drivers support, regardless of whether or not you have the latest headers and libraries. That's really helpful for Windows, because it's stuck back in OpenGL 1.1. On other platforms we have updated headers and libraries, although one benefit I see is if people on other platforms don't have the latest OpenGL headers/libs, GLEW will make the functionality available anyway (like it does on Windows). On the other hand, if they don't have the latest OpenGL headers/libs and don't know how to upgrade them, they probably aren't going to have GLEW or know how to install it.

[thelusiv]

I read through the GLEW code a while back and the biggest thing I think we could draw from it if we used it more heavily, is that it has a good bit of code for lots of different platforms defining what is available or not (Darwin, Solaris, BSD, Linux, various different sections for NVIDIA and ATI). I think the big issue is that we assume that Linux and other OS users are using the latest headers. I don't think that's always necessarily true. Again, I'm not an OpenGL expert of any kind but Joe I think you should read the code for GLEW and see if you could put it to work in the CARDINFO class. I guess my statements before about replacing/changing CARDINFO to use GLEW were a bit poorly worded, I guess what I was trying to say was, could it be used to make the CARDINFO class more robust...?

[joevenzon]

As noted before the cardinfo class only has 1 line where it asks what the card supports. The information returned is provided by the graphics card driver, which seems to me like the authoritative source (after all, it knows exactly what card is installed and what it's capable of). There's no reliance on extensions or fancy headers anywhere in the cardinfo class.

[mak77]

actual svn compiles fine (adding missing headers from libvorbis and libogg to tools/win/include) and icon still added to executable...
I've run it in Vista and (giving the correct rights on the folder due to the creation of stdout and stderr) it works, i've been able to drive on Laguna Seca

[thelusiv]

Sounds good mak77, I'll update the build for libvorbis soon.