6.136 gl.TexEnv
NAME
gl.TexEnv – set texture environment parameters
SYNOPSIS
gl.TexEnv(pname, param)
FUNCTION
A texture environment specifies how texture values are interpreted when a fragment is textured. pname can be either #GL_TEXTURE_ENV_MODE or #GL_TEXTURE_ENV_COLOR. If pname is #GL_TEXTURE_ENV_MODE, then param must be the symbolic name of a texture function. Four texture functions may be specified: #GL_MODULATE, #GL_DECAL, #GL_BLEND, and #GL_REPLACE.
A texture function acts on the fragment to be textured using the texture image value that applies to the fragment (See Section 6.141 [gl.TexParameter], page 199, for details.) and produces an RGBA color for that fragment. See an OpenGL reference manual for information on how the RGBA color is produced for each of the three texture functions that can be chosen.
If pname is #GL_TEXTURE_ENV_COLOR, param must be a table containing an array that holds an RGBA color consisting of four floating-point values.
#GL_TEXTURE_ENV_MODE defaults to #GL_MODULATE and #GL_TEXTURE_ENV_COLOR defaults to (0, 0, 0, 0)
Please consult an OpenGL reference manual for more information.
INPUTS
- pname specifies the symbolic name of a texture environment parameter (see above)
- param table or single value specifying the parameter
ERRORS
#GL_INVALID_ENUM is generated when pname is not one of the accepted defined values, or when param should have a defined constant value (based on the value of pname) and does not.
#GL_INVALID_OPERATION is generated if gl.TexEnv() is executed between the execution of gl.Begin() and the corresponding execution of gl.End().
ASSOCIATED GETS
gl.GetTexEnv()

So my questions are:
- Could it be possible that the gl.TexEnv() is causing the texture problem on MOS? On Windows it works just fine.
- What is the right syntax of gl.TexEnv() : it uses two parameters or three?
- #GL_TEXTURE_ENV isn't mentioned anywhere in the manual

The documentation of gl.TexEnv() is correct. It uses two parameters so your code is ok. It's a bug in the Warp example. The same bug is also in Gears3 and GLMatrix but it doesn't seem to have any practical consequences. Still I have fixed all those examples of course so thanks for reporting.

Concerning the gfx glitches: If it works on Windows, Mac OS, and Linux, it's very likely to be a TinyGL issue. Have you tried it on MiniGL (OS4)? Does it work correctly there?

I've just tested Hasteroids on MiniGL and TinyGL and it works on neither. I'm afraid the only solution is to cut down the code and see what's causing the problems. It's very unlikely that this is a GL Galore bug since it just wraps MiniGL and TinyGL functions.

Allanon wrote:unfortunatly not having a MOS machine it could be a difficult task

Luckily MorphOS compatible Macs don't cost much anymore. For example, a cute and small Mac mini or some G4 laptop, which doesn't take your deskspace either, don't cost more than something like 20-50e nowadays. And you can test MorphOS stuff without buying the OS by its 30min demo mode (reboot every 30mins). Check compatible machines here for instance.

Allanon wrote:unfortunatly not having a MOS machine it could be a difficult task

Luckily MorphOS compatible Macs don't cost much anymore. For example, a cute and small Mac mini or some G4 laptop, which doesn't take your deskspace either, don't cost more than something like 20-50e nowadays. And you can test MorphOS stuff without buying the OS by its 30min demo mode (reboot every 30mins). Check compatible machines here for instance.

Ehehe... thank you for the tips but the problem is the space and my mind sanity
Actually I have :
- Windows 10 notebook as development machine
- Linux Box on real hardware + Linux on virtual machine for quick tests
- MacOS Mini 10.10.2 (Intel) + MacOS on Virtual machine for quick tests
- IndieGo console (Linux ARM)
- A gaming PC (right now with a broken HD )
- PS3 (collecting dust due to lack of time )
- WinUAE with thousand of configurations
- A real A1200 + 030
- A MSX2 collecting dust (not related with Hollywood but I'd like to start to play with it )
not to mention Arduino, PS2 (real), emulators, etc...

airsoftsoftwair wrote:FWIW, on MiniGL Hasteroids only shows a white screen and nothing else whereas on MorphOS there are some graphics at least, albeit with glitches

I haven't digged yet into this problem but I think it is something related with how the texture are encoded or loaded, from the MOS screenshot it's clear that only the textures loaded from the disk are messed up, instead the brush used to print the stats it is visible and without glitches...

Thanks to the unvaluable help of emeck I've finally found out that the glitches produced on MorphOS are related to the texture sizes, if the brushes, which are converted into textures, have width and/or height not power of 2 the garbage is produced.

I'll post a test program soon so people interested in this subject can have a go on their machines

Yes, I think in very old OpenGL versions it was necessary for textures to use sizes that are a power of two. Starting with OpenGL 2.0 and up this isn't necessary any longer but on Amigaoids we of course still have very old OpenGL versions.

I could of course modify gl.TexImageFromBrush() to add padding for systems that require power of two textures but I don't think that this is a good idea because the script would then behave differently on non-power-of-two-systems than on systems that require power of two textures. Maybe I could add an optional argument to gl.TexImageFromBrush() that forces the command to add padding space to power of two on *all* platforms. But it's also quite easy to do this on your own I guess...