Okay, so Mark knows this already, and some other people probably do too, but here's my description of how this works for anyone who doesn't know... (correct me if I'm mistaken)...
BlitzMax starts its OpenGL support at version 1.1
In order to make it easier to update BlitzMax with a newer version of glew, to support newer versions of OpenGL and new extensions, Mark (or someone) wrote a conversion program, glew2bmx.bmx, which is in the mod/pub.mod/glew.mod/ folder.
This program takes a glew.h header file (which is part of the standard glew distribution package, and which is kept in mod/pub.mod/glew.mod/GL/), parses it and converts it to the appropriate BlitzMax calls. The calls it generates sets up constants, and function references to external C functions. The C functions are stored in glew.c which is also part of the glew distribution package.
Glew.c does the hard work of the actual glew system, while mod/pub.mod/glew.mod/glew.bmx and mod/pub.mod/opengl.mod/opengl.bmx contain the blitz-converted version of glew.h
When you compile and run glew2bmx.bmx, it does not write any files. It simply print output text to the output console of the BlitzMax IDE. The text generated after the `executing [programname]` line, starting with `Const GL_ACCUM=$0100`, down to `Function glViewport(x_:Int,y_:Int,width_:Int,height_:Int)` define OpenGL 1.1 commands and constants. If GL1.1 was ever updated (which it won't be), you'd copy all lines from the Const GL_ACCUM line down to the glViewport line (inclusive) should be copied and pasted into the mod/pub.mod/opengl.mod/opengl.bmx file. You should already have this file and all of the GL1.1 stuff defined as a standard Blitzmax module file. It has a few other things in it besides just the copied text - e.g. it also imports glu.bmx (which does not need updating).
The rest of the text in the output window (from running glew2bmx.bmx), from `Global GL_VERSION_1_1:Byte="__GLEW_VERSION_1_1"` down to the line before `Process complete` needs to be copied and pasted into the mod/pub.mod/glew.mod/glew.bmx file. This is also a standard blitzmax module file with a few other things in it, including the undocumented glewinit() function.
Currently BlitzMax has code output from glew 1.3.4, which supports OpenGL 2.0 plus some additional extensions added in that version of glew, but it does not support OpenGL 2.1 or higher (unless via existing extensions). To support OpenGL 3 official commands, or additional recently added extensions, you need to download the latest glew package, copying the output (GL1.2 onwards) into glew.bmx - and glew.c needs to be in the glew.mod folder. The GL/ subfolder needs to contain glew.h, glxew.h and wglew.h. See http://glew.sourceforge.net/
Once you've downloaded the latest version and put the files in the appropriate folders, you can run glu2bmx.bmx and copy the partial output to glew.bmx
Now, the way I understand it, glew.bmx contains function definitions for all versions of GL (up to whatever glew supports) and all known extensions in that version of glew. It is not necessary for the computer that blitz runs on to support all of these commands. For example, I know that OpenGL on my ibook does not support GL2, it's more like 1.4 or something, and yet BlitzMax's glew.bmx has gl2.0 commands in it.
To use OpenGL 1.1 commands you do not need to do anything for them to be available in your programs (unless you're using Import, then you have to import the OpenGL.mod). The target machine doesn't even need to have ANY opengl driver for blitzmax to work, but if you try to call an opengl command it probably won't do anything (?! or bomb out?).
If you want to use GL 1.2 or above, or any extensions, then you have to call glewInit() first from your program. This will (I am guessing) go look at the GL driver and find out what features are supported, what extensions are available, what GL version, etc. It would then `map` the Blitz functions to glew's version of those functions (in C), and would presumably map to Null() if the feature is not available (?). Since glew defines commands which may not be supported on the target machine, you can conceivably call them, but if you don't check for their availability first then will get some undefined result? Or no result? Or a crash?
This is where using stuff like glGetString comes in handy for getting a list of what version of opengl is supported and what extensions are supported. You would have to sort of `manually` make sure that you don't call a function that GL says is part of a version or extension that isn't supported on the target machine. So an essential part of using GL 1.2 or higher or extensions, is to first test GL to see what the driver supports and then call your code to use functions conditionally, based on availability. I almost think I read somewhere that if a function is not supported it will simply return Null or do nothing?
The nice thing is that once you define your glew.bmx file with all the latest commands/extensions/constants, and you update your C files of course, you at least get a nice list of all the available functions and constants (which comes in handy for me in my project). Even if the target machine doesn't support everything, you at least know what they are, so you can write your code and still be using legal function names.
I always did wonder how Blitz was auto-defining Gl/extension functions - they're already defined! :-)
One thing I also learnt while figuring this out is the way you set up references to external functions and constants in C files - might come in handy for future modules. The ="something" after the function name is basically the name of the function in the C file, and it can be different than what you're calling it in BlitzMax.
Cool beans. Let me know if anything I've said is not correct, and perhaps we can clarify about whether unsupported functions return Null or call Null().
|