[opengl.mod] Incorrect type for constants GL_FALSE and GL_TRUE

[MrMisanthrope]

Whilst building some example code which relies on sdl.mod/gl2sdlmax2d.mod I came across a problem with the definition of the GL_FALSE and GL_TRUE constants in opengl.mod.

As GL_TRUE and GL_FALSE are of GLboolean type, then they are essentialy 1 Byte sized which leads to compilation errors under BlitzMax NG as it declares them as default size type (Int) in the opengl.bmx file.

There are also inconsistencies in other places where True/False (BlitzMax type) is used instead of GL_TRUE/GL_FALSE and this also throws up the same error.

The error being: Argument #n is "Int" but declaration is "Byte"

Fix:
Change definition of lines 104 & 105 in pub.mod/opengl.mod/opengl.bmx

Const GL_TRUE=1
Const GL_FALSE=0

to...

Const GL_TRUE:Byte=1
Const GL_FALSE:Byte=0

Furthermore, any use of BlitzMax NG True/False under OpenGL use should be changed to GL_TRUE/GL_FALSE to prevent the same error.

[GWRon]

I brought this issue up some days ago at our discord server:

eg some GL-Calls in mojo.mod which accept :byte blame now that false or true is passed. We also cannot simply use GL_FALSE and GL_TRUE there, was they are also defined as int (in a non-superstrict way, so const GL_TRUE=1)
[We] could now define them as byte as the original definition is typedef unsigned char GLboolean ... so guess byte is what originally was to use there ...
Anyways it feels so super odd that True/False is defined as integer (and thus cannot be used where it expects bytes ... and you cannot do False:Byte)... maybe True/False could become a byte

Message: https://discord.com/channels/613699895139762176/679291789840089108/1336249886785405020

The follow up message was about the "byte/int"-warnings in general:

I know I already brought it up ...

    Field drawColor:SDLColor = New SDLColor(255, 255, 255, 255)
    Field clsColor:SDLColor = New SDLColor(0, 0, 0, 255)

... this looks clean and nice ... but creates warnings because 0 and 255 are integers ...

Compiler wants you to write:

    Field drawColor:SDLColor = New SDLColor(255:Byte, 255:Byte, 255:Byte, 255:Byte)
    Field clsColor:SDLColor = New SDLColor(0:Byte, 0:Byte, 0:Byte, 255:Byte)

(or to have an overload accepting integers)

I understand that you cannot simply make constant values <= 255 bytes... because then bitshifting would no longer be "backwards compatible". My current solution (in this case is to use an int,int,int,int-overload ...)

This is btw surely why Max2D's setColor is using ints:

Rem
bbdoc: Set current color
about:
The #SetColor command affects the color of #Plot, #DrawRect, #DrawLine, #DrawText,
#DrawImage and #DrawPoly.

The @red, @green and @blue parameters should be in the range of 0 to 255.
End Rem
Function SetColor( red:Int,green:Int,blue:Int )
	TMax2DGraphics.Current().SetColor(red, green, blue)
End Function