The OpenGL ES 2.0 thread

@Daytona675x

Nice.

OpenGL ES 2 version 2.7 for Warp3D Nova / AmigaOS4 is on my FTP for testers to test now!

- Fix: my internal VBOs must initially set to what I internally call "emulation" mode, otherwise one dummy glVertexAttrib call per used generic VA-attribute-index was eventually necessary to get standard-conforming behaviour because that call would also set that flag. This problem was unlikely to happen in real world though because usually no program would rely and use the 0,0,0,1 generic vertex-attribute's default value, instead practically every real world program would call glVertexAttrib anyway. Still, it was a bug. It was revealed as a side-effect in one of Juhas test-programs.

- Fix: dos.library isn't closed anymore... Closing it was the reason for the OS becoming unstable if you tried to delete / replace (it was closed on lib expunge) ogles2.library after running an ogles2 client program.

Those two from above were in 2.6 already, but I didn't write a notification info back then. And then there is this:

- added support for GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL to glTexParameter and glGetTexParameter. Requested by Caras for AmiCraft. This allows you to adjust the limits of a texture's mipmap-chain. Was a bit tricky because for Nova those are attributes of the texture-data whereas the other glTexParameter-equivalents are attributes of the texture-sampler. And while the texture-sampler is always present, the texture-data is not until e.g. a glTexImage-call. Therefore those new attributes have to be handled in a quite different way and also have to be mirrored by ogles2.library.

- glGenerateMipmap now uses the values of GL_TEXTURE_BASE_LEVEL and GL_TEXTURE_MAX_LEVEL instead of always using 0 and 1000 respectively.

- added support for GL_TEXTURE_MIN_LOD, GL_TEXTURE_MAX_LOD and GL_TEXTURE_LOD_BIAS to glTexParameter and glGetTexParameter. Roughly spoken those allow you to tweak the GPU's mipmap selection. Had to adjust some internals because in contrast to all the other supported parameters those are floats, not integers.

- consequently added GL_SGIS_texture_lod to the extension string.

- added support for glGet GL_MAX_TEXTURE_LOD_BIAS. Note: as of now Nova doesn't support a true query for this, so for now I return 16, which is what high-end Radeons support for sure.

- added GL_EXT_texture_lod_bias to the extension string. Note that it's not exactly matching the extension's definition. The reason is that there was no GLES2 implementation which supported that feature until now And in later GL versions it is core functionality. So this old EXT was the best match I found.

- added support for the wrap-mode GL_MIRROR_CLAMP_TO_EDGE (which is actually an OpenGL 4.4 feature ).

- consequently added GL_ARB_texture_mirror_clamp_to_edge to the extension string.

- Fix: nobody noticed, but glGetTexParameter returned Nova-enum-values instead of GL-enum-values for GL_TEXTURE_MAG_FILTER, GL_TEXTURE_MIN_FILTER, GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T.

- Fix: if a mipmaped texture was made non-mipmap, then the minification mode had to be adjusted eventually. Nobody noticed, but by accident I applied it to the magnification setting...

- Fix: in 99% Nova's default state values are identical to those of OpenGL. One exception is the texture filtering though, Nova defaults to "nearest" whereas OpenGL defaults to GL_NEAREST_MIPMAP_LINEAR for minification and GL_LINEAR for magnification. Forgot to enforce those. Went unnoticed so far because any half decent program would not rely on or use such defaults. But Kas1e managed to find some which do

- Fix: under certain circumstances the lib tried to hash the data behind what it at that code-location falsely thought was a vertex attrib pointer, when in reality it was a non-zero VBO offset. This fixes the crash with Capehills SDL testdraw2 if batching enabled.

- from now on the archive also contains an unstripped version of the lib which contains debug symbols, as requested by Kas1e.

- !don't forget to download the new include-folder too!

- version set to 2.7 (13.4.2019)

Cheers,
Daniel

@Daytona675x

Is your ftp available for testers or is it closed-source?

@Raziel
Or? ogles2 is closed source. My ogles2-ftp-directory is available to a-eon-approved testers.
However, I post such progress info to the public simply to inform all interested Amigans on the progress.

@Daytona675x

Thank you, i was just curious.

It's nice to be able to follow development up close for a change (as a non-beta tester, non-developer and non-facetwitter user)

OpenGL ES 2 version 2.8 for Warp3D Nova / AmigaOS4 is on my FTP for testers to test now!

- Hotfix: kas1e reported some ugly artefacts at least in one Quake3 level. It looked much like the symptoms of the hasher-bug which got fixed in 2.2. And indeed: turning off the whole hash-optimizations made the bug go away (and Q3 crawl) But in fact the bug had nothing to do with it and the hashers are just fine

It was "simply" a missing Nova-flush at one point and it wasn't a wrong VBO but a wrong texture being used. Turning off the hashers only made the lib invoke the missing flush elsewhere and so it appeared to fix it...

Fixed. Unfortunately this fix comes with a performance penalty, which is measurable (for some progs more than for others) but not really severe, unless you're running a benchmark.

- version set to 2.8 (16.4.2019)

Cheers,
Daniel

@Daytona675x

Is there a way to check if an exe has been built with ogles2 support?

With MiniGL/Warp3D there is this information stuff coming up

Quote:
Some rudimentary info with ogles2 would be neat as well.

@Raziel
I'm not sure that I really understand your question, but I'll try.

Quote:
Hm, well, grep the exe for "ogles2.library"? Is probably good enough in most cases.

Quote:
This info comes up because somebody wrote code in the respective program to show that info.
ogles2.library offers the full OpenGL ES 2 API. That means it also supports the functions glGetString and glGet.

Quote:
Both those functions can be used to produce output like your above quote, and much more.

You only have to use those functions. Such output doesn't magically appear out of nowhere.

@Daytona675x

The reason i'm asking is to find out if the recompiles (i recently learned that a "port" differs from a "recompile") of ScummVM and ResidualVM actually use ogles2 on start.

If you remember i had shader problems on (scummlvm) start and missing functionality (boolean uniforms --> residualvm).

With 2.8 installed i can recompile and start at least the ScummVM binaries without shader errors or in-program oddities, so i was wondering if these features has been added in the meantime (since both projects did not change anything in that regard, at least not that it caught my attention).

Though, if it would be actually be compiled in and used/running with ogles2, how could i determine that it *is* used?
Because right now there is no speed gain to be seen.

Also grepping the exes reveal that both the ogles2 explicit build *and* the SDL2 build have ogles2.library in it's compiled code (only the SDL1 version lacks it)

...and yes, i'm recompiling three different versions of both projects to keep track with the changes and be able to point out bugs in the process...

@Raziel

Didn't Capehill and Kas1e recently write some lib call interception tool?
Maybe you should give that one a try!

@Raziel

You could add something like



in your application, after the GL context has been created. In SDL2 scenario, locate SDL_GL_CreateContext call first.

I didn't test or even compile the above but hopefully it demonstrates the idea.

EDIT: apparently ResidualVM does this: https://github.com/residualvm/residual ... englsdl-graphics.cpp#L154

Maybe ScummVM doesn't? Feature request for ScummVM devs?

@Capehill
Btw, you may add to the list 2 new huno's ports too which works over gl4es and his egl wrapper (so all works over ogles2 and warp3dnova):

demo: "glexcess"
http://hunoppc.amiga-projects.net/con ... glexcess-eglwrap-amigaos4

game: "pacman arena":
http://hunoppc.amiga-projects.net/con ... pacman-arena-eglwrap-aos4

@all

Question about gl_FragCoord behaviour: according to https://www.khronos.org/registry/OpenG ... 4/html/gl_FragCoord.xhtml , the origin is at the lower left corner.

To me it seems that the AmigaOS 4 origin is at the upper-left corner. If I multiply white color by gl_FragCoord.x/y coordinate divided by window w/h, the white gradient is at the lower-right part of the window, instead of the expected upper-right.

Anybody could clarify what is correct behaviour? Demo program available (later).

@Capehill

Sounds like a driver bug. It should be behaving as per the OpenGL spec.

Please submit a bug report against Warp3D Nova.

Hans

@Hans

Thanks, Mantis ticket 410.

@Daniel

It seems that OGLES2 passes nullptr as "errCode" parameter for W3DN_CreateFrameBuffer, can you confirm that errCode is wanted to be ignored here, by OGLES2?

@Capehill
Dunno what you're digging for, but yes, this is what I intended to do and what's implemented. This Nova error code parameter is optional and I don't care about it / don't need it.
I'm OpenGLES2 and as such I'm only interested in if the operation failed and not why. And the if is covered by the function's return value already.
Because of that you'll probably find lots of places where I pass nullptr for a Nova errCode.

@Daytona675x

Thanks for confirmation, glSnoop can handle these better now.

@Daytona675x

Quote:

Yes, he indeed did and what a neat little program that is.
Successfully used to confirm OGLES2 running.

Thanks for the hint.

OpenGL ES 2 version 2.9 for Warp3D Nova / AmigaOS4 is on my FTP for testers to test now!

- Fix: if an enabled vertex-attribute-array was being disabled then the corresponding generic vertex-attribute wasn't applied eventually, resulting in semi-random vertex-attribute data. This will rarely happen in a real-world app, which is why this bug wasn't found earlier. Thanks to Capehill for reporting!

- extension to the glGetString GL_VERSION query: it will now not only return the ogles2 lib's version but also the Nova version! Programs should check both versions because especially GLSL functionality depends on Nova, not so much on ogles2. The returned string now looks like this:
"OpenGL ES 2 2.9 on top of Warp3D Nova 1.65"
Thanks to Raziel for indirectly inspiring me to do this one

- and for convenience (or if you find it too hard to parse the 2nd version number (cough, Entwickler-X-Frank, cough ) which may appear at different positions depending on the 1st one) the Nova version number is also appended to the GL_RENDERER string which now reads like:
"Warp3D Nova 1.65"

- Implemented the OES_get_program_binary extension as requested by kas1e. Because Nova doesn't provide any support here, this implementation works with the internal SPIR-V code of all shaders that make up the respective program. So the binaries here are no true machine-code but intermediate code, packed into a proprietary format. Providing such binaries essentially skips the vertex- and fragment-shader's GLSL compilation steps. Anyway, this means:

- new function glGetProgramBinaryOES to extract such a binary representation of the respective successfully linked shader program.

- new function glProgramBinaryOES to supply the GL with such a cached binary.

- support for the glGet parameter GL_NUM_PROGRAM_BINARY_FORMATS_OES - which returns 1 now.

- support for the glGet parameter GL_PROGRAM_BINARY_FORMATS_OES, which returns one single format ID identifying my binary format (0xC00DA675)

- support for the glGetProgramiv parameter GL_PROGRAM_BINARY_LENGTH_OES which gives you the buffer size required to store the binary for the respective program.

- consequently added GL_OES_get_program_binary to the extension string.

- added glProgramBinaryOES and glGetProgramBinaryOES to the stubs-library for direct use.

- Fix: aglGetProcAddress returned function pointers in the Amiga interface style, with the first parameter being a pointer to the interface. Now the compatible "stub"-style signature is being returned which matches the GL function pointer prototypes.
Apparently nobody used aglGetProcAddress before, so this went unnoticed. On our ogles2.lib even the extension functions are all simply directly accesible just like all other functions, so if you code for Amiga only you don't need aglGetProcAddress.
gl4es however uses it - and this was where it all exploded now Thanks to kas1e for reporting..

- !don't forget to download the new include-folder too!

- version set to 2.9 (23.7.2019)

Thanks to kas1e for testing!

Cheers,
Daniel