How easy would it be to implement OGL 3.0 in BMAX

BlitzMax Forums/OpenGL Module/How easy would it be to implement OGL 3.0 in BMAX

monotonic(Posted 2008) [#1]
Hi,

I'm seriously thinking about buying BMAX but, from what I have read BMAX only supports v1.1 of OGL. Now my question is how easy would it be to implement OGL v3.0 when it is released?

Thanks in advance.


JoshK(Posted 2008) [#2]
Very easy.

However, I think OpenGL 3.0 maybe have been cancelled. They were supposed to have it out 6 months ago, and no one is saying anything, which indicates to me they are having legel/IP problems. Software patents in action.

OpenGL 3 is really just an API cleanup and removal of a lot of obsolete functions. OpenGL 2.1 can do everything DirectX 10 can right now.


ImaginaryHuman(Posted 2008) [#3]
From 1.1 you can use GLEW to access any other extensions that you need, which will include all functionality in the official 2.1 or whatever.


monotonic(Posted 2008) [#4]
Ahh ok, so I take it this is already built into BMax?

Thanks guys, that clears things up.


@Leadwerks

I will be using your engine with BMax anyway, I just wanted to play around with the OpenGL stuff until I build a good enough machine to run LWE.


ImaginaryHuman(Posted 2008) [#5]
Yeah you initialize Glew and then you can get access to extensions. All the extensions together would officially make up the equivalent of GL 2.0 or whatever. I think they change some of the extension names or whatever, but hey. And you have to test to make sure the extensions you want to use are supported on the computer you are running on.


Yahfree(Posted 2008) [#6]
So it's already GL 2.1? Or do you have to add the extensions manualy? Curious.


Dreamora(Posted 2008) [#7]
You might have to update GLEW yourself. I think someone mentioned that it is a little outdated and "only" on OpenGL 2.0 (which already is more than your hardware supports of the leadwerks engine does not work on it)


ImaginaryHuman(Posted 2009) [#8]
I am curious about this need to update Glew. I did see online somewhere that the glew library itself had to go through updates in order to support newer gl commands. So does that mean that if I want to use an OpenGL 3 feature I will have to somehow implement a more recent version of glew in order to make the functions available?


ImaginaryHuman(Posted 2009) [#9]
Anyone?


nawi(Posted 2009) [#10]
If GL_VERSION_1_1
	If GL_VERSION_1_2
		If GL_VERSION_1_3
			If GL_VERSION_1_4
				If GL_VERSION_1_5
					If GL_VERSION_2_0
						Print "GL 2.0"
					Else
						Print "GL 1.5"
					EndIf
				Else
					Print "GL 1.4"
				EndIf
			Else
				Print "GL 1.3"
			EndIf
		Else
			Print "GL 1.2"
		EndIf
	Else
		Print "GL 1.1"
	EndIf
Else
	Print "GL ?.?"
EndIf

The constant for GL_VERSION_2_1 is missing, so I think 2.1 is not supported.


ImaginaryHuman(Posted 2009) [#11]
Oh. So the default version of glew that BlitzMax has, supports GL up to 2.0, and anything above that is going to need a new version of the glew library wrapped, right?


nawi(Posted 2009) [#12]
https://sourceforge.net/project/downloading.php?group_id=67586&filename=glew-1.5.1-src.zip
You can find glew.c, glew.h, glxew.h and wglew.h from that zip file, then open glew2bmx.bmx and read instructions. I think that is all that is needed for GL 3.0, I don't have access to BMX currently so I can't try.


ImaginaryHuman(Posted 2009) [#13]
Cool, I will try it and see how it goes.

Question - if I update glew like this, does it cause BlitzMax apps to `require` OpenGL 3, or will it still work when there is only GL1.1 available?

Question - The glew2bmx program outputs all the constants and stuch, but instead of outputting functions it outputs Global, then the function with params, and then often ="__glewsomething". I don't see those kind of function equators in the opengl.bmx file - so do they belong there? Do I need to edit it a bit?


nawi(Posted 2009) [#14]
Sorry, can't help you there buddy.


ImaginaryHuman(Posted 2009) [#15]
Example:
Global glCopyTexSubImage3D(target_:Int,level_:Int,xoffset_:Int,yoffset_:Int,zoffset_:Int,x_:Int,y_:Int,width_:Int,height_:Int)="__glewCopyTexSubImage3D"

becomes...
Function glCopyTexSubImage3D(target_:Int,level_:Int,xoffset_:Int,yoffset_:Int,zoffset_:Int,x_:Int,y_:Int,width_:Int,height_:Int)

????
I don't see ANY extensions being defined in opengl.bmx, just the standard gl1.1 stuff. And yet BMax lets you use extensions from 1.1, so this stuff must be defined somewhere else in blitzmax?

e.g. if I call glCopyTexSubImage3D(), which is a GL 1.2 command, blitz recognizes the command and tells me I am missing some parameters. So that's obviously defined somewhere and used by blitzmax, but not in the opengl.bmx file. Perhaps it's in the glew.bmx file in the glew module? (i'll check there)


ImaginaryHuman(Posted 2009) [#16]
Okay now I'm getting somewhere.

In the pub.glew.mod module, ie glew.bmx, you see the same kind of code which is output from the glew2bmx.bmx program - but not all of it. As per the instructions in that program, it starts after the glViewport definition from gl1.1:
Function glViewport(x_:Int,y_:Int,width_:Int,height_:Int) 'does not appear

Global GL_VERSION_1_1:Byte="__GLEW_VERSION_1_1" 'appears as the first line

So it appears that you run glew2bmx.bmx, then cut and paste the output window's text from just after the glViewport function, down to the bottom (not including program finished messages), and paste it into/replace the definitions in glew.bmx


ImaginaryHuman(Posted 2009) [#17]
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().


beanage(Posted 2009) [#18]
Thanks for this last post, ImaginaryHuman. Just helped me out alot understanding how the max glew implementation works.