The OpenGL ES 2.0 thread

Added GL4ES link.

@Daytona675x

1) Are you able to compile GLES2/gl2ext.h? I just tried and I had to add this kind of hack:



2) About GL_ARB_texture_rectangle: I couldn't find define for GL_SAMPLER_2D_RECT_SHADOW. It was mentioned here https://www.khronos.org/registry/OpenG ... ARB_texture_rectangle.txt

3) About GL_EXT_texture_lod_bias: I couldn't find define for GL_TEXTURE_FILTER_CONTROL_EXT. It was mentioned here https://www.khronos.org/registry/OpenG ... /EXT_texture_lod_bias.txt

4) About GL_ARB_provoking_vertex: is QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION missing the GL_ prefix?

@Capehill

1) hm, yes, I can (if I include gl2.h before, of course), but who knows, maybe there is some side-effect with your concrete use-case somewhere. Please upload a project incl. your makefile for me to try.

2) our ogles2 doesn't support the GL_EXT_shadow_samplers extension as of yet. Therefore the rect-texture extension lacks the shadow-part too - which is why I didn't care about such defines as of yet

3) we are in ogles2, there is no "texture environment". Therefore there aren't defines for parameters which are required only for not-existing functions like GetTexEnvfv, GetTexEnviv, TexEnvi, TexEnvf, Texenviv, and TexEnvfv.

4) yes, thanks, fixed!

@Daytona675x

1) Fixed by including GLES2/gl2.h - thanks. I was only including proto/ogles2.h before. https://github.com/capehill/glsnoop/co ... e48c7593f690f410062cd5aec

@All
I am not Daniel, but as there is XMAS time and everyone is busy, and news on amigans.net is didn't appears with changelog, there is what was changed since v2.9 up to current 2.11:


- Fix: glScissor didn't gracefully handle negative XY or height. Thanks to Kasie Kasovich (kas1e) for reporting.

- Improvement: under certain circumstances, ogles2 could be triggered to resize its internal client-RAM-emu-VBOs multibuffer to very very large values, in fact so large that Nova allocated almost all VRAM for those. At least on some Nova/RadeonHD.chip/graphics.lib setups the VBO resizing also triggered a crash bug in Nova's DeleteBuffer function under such low VRAM conditions. This improvement therefore also acts as a workaround for that issue. This fixes all such issues with some of kas1e's Irrlicht engine examples. Thanks to Kasie Kasovich (kas1e) for reporting.

- Fix: there was a bug in the copy-converter for 8bit and 16bit index arrays (Nova doesn't support 8bit indices and is very slow with 16bit indices, therefore those are converted to 32bit internally, even if the ogles2-client passes them inside his own VBO, then a "hidden" 32bit clone is prepared and used) which in theory could result in the indices not being updated at all. It was extremely unlikely to happen and AFAIK it never did, but anyway: fixed.

- Workaround/Fix: if you attached a GL_BGRA_EXT texture as color render target to an FBO, then the texture's red and blue channels would appear to be swapped when you later used that texture for rendering. The reason for this is that the BGRA texture's internal pixel format is actually RGBA, only that its channels are "swizzled". At the moment Nova ignores that swizzle setting when rendering to the texture. The current workaround is to reset any eventual swizzle to the defaults if the texture is being used as FBO render target, so simply spoken an BGRA texture becomes an RGBA texture if you use it as render target. This fixes color bugs in e.g. an irrlicht demo and Tuxkart. Thanks to Kasie Kasovich (kas1e) for reporting.

- maintenance, C++ modernizations: all attribute initializations moved from constructor initializer lists into the respective class definitions. Makes the code smaller and it's harder to forget something (and oops, I actually found one uninitialized attribute during the process (uncritical though)...).

- maintenance, C++ modernizations: "auto" return-value replacement run on all inline functions, where appropriate.

- (small) hashing functions speed-up (without hash quality loss).

- Fix: a bug in the uniform shader variable handler resulted in same-named (and thus logically identical) vertex- and fragment-uniforms to eventually be assigned different virtual location numbers. If the user issued a glUniform(location_number,xyz) call then the lib would only find and set the vertex-shader's uniform and skip the writing to the fragment-shader's uniform because it would simply not find it. OpenGL doesn't distinguish between such same-named but physically different uniform variables in the shaders of a GPU program - in stark contrast to Nova, where all that info is shader and not shader-program based. Consequently Nova's ShaderGetObjectInfo, which is used to query uniform variable information, works on shaders only. Also, Nova only gives us a GLSL / GL compatible "location" info if that has been explicitly defined inside the shader, otherwise, it doesn't generate one but only returns W3DN_NOLOCATION. Because of all this ogles2.lib has to generate such location Infos by itself, in a GL compatible way. This means that in case of a same-named variable in both of a program's shaders the same uniform location has to be enforced. Which is where the flaw was. In gl4es this bug manifested in a fog not working. Thanks to kas1e for reporting and testing!

@Daytona675x

There is a small typo in GL_VENDOR string of 2.11. Extra 't' if I recall correctly.

By the way, how to interpet the GL_SHADING_LANGUAGE_VERSION string? I guess I'm looking for the meaning of 0.9 here.

@Capehill
Quote:
LOL, indeed, thanks

Quote:
Well, not at all. The thing is that I didn't really know what to put there because Nova lacks commands etc. which are mandatory, that's why I put this 0.9 there, to refect this. I will re-check current Nova state and reconsider this string's content for the upcoming ogles2 update.

@Daytona675x

Should it be possible to resize an FBO color attachment? I'm trying to use glTexImage2D to make texture match the changed viewport size but it seems to result in garbage output without GL or Nova errors.

I suppose it might be possible to re-create the FBO but it sounds a little bit overkill.

EDIT - this seems to work:

1) bind FBO
2) remove color attachment
3) resize texture
4) add color attachment again

@Capehill
It should be possible if you use glTexImage2D and then call glFramebufferTexture2D again to explicitely update / notify the FBO accordingly.
I have to admit that I'm not sure about what the specs say here, whether a call to glFramebufferTexture2D is required or not / whether glTexImage2D should internally take care by itself that an FBO the texture is attached to gets updated.
But at this time our ogles2 wants you to call glFramebufferTexture2D again, unless Nova internally readjusts things (if you got garbage that could be an indicator that Nova doesn't care neither without an explicit FBBindBuffer or so).

EDIT: woops, apparently our last postings overlapped
EDIT2: from what I read now so far it seems that this is a standard violation in my ogles2 implementation, it should be enough to call glFramebufferTexture2D once to establish the connection. A resize of the texture via glTexture2D should from then on automatically trigger eventual FBO updates under the hood. I'm going to fix this asap.

@Daytona675x

Ok. After some quick testing it seems that still have to remove the old color attachment before resize by glTexImage2D. Could it be that OGLES2 ignores further attachments with same texture name (!= 0)?

@Capehill
Yes, you are right, it doesn't trigger an FBO update if the same texture is being reattached. So right now a dummy attach(0) would be required a.t.m., just as you outlined above.

@Capehill
There's an ogles2_3_capehill.zip on my FTP for you.
Now a glTexture2D should be enough, totally untested, of course , crossing fingers .
If it doesn't work then please mail me your latest exe for me to try.

@Daytona675x

It worked partially, I could see animation in the original portion of the texture but as I increase the window size, pinkish garbage appears in new parts.

I try to create a test package..

@Capehill
Yo, done, new regular ogles2_3_wip.zip has been updated accordingly. The reason why it didn't work in my previos first shot from above was that I forgot to update the internally cached FBO width / height...

@Daytona675x

Working well, thanks. Tried even with 4 FBOs at the same time.

Is there any estimate when v3.0 will be released to the public?

@Capehill
Quote:
Yes, and it should also work if you attach the same texture to multiple FBOs. Also measures have been taken so that glTexture2D doesn't cost extra time in general. Was no 1-liner

Quote:
It should be inside the next official Enhancer update. Talked to Matthew about that yesterday.

@Daytona675x

Shadertoy uses floating point textures for Buffers A-D. For Shaderjoy, I am creating those like:



When using these with FBO there is a dot-like pattern produced along the triangle border but also in other places when there is enough contrast (?) between pixels. It sounds like a Nova issue but do you want test it yourself?

@Capehill
Daniel didn't have access to amigas for today, so he ask if you can mail him the test-case.

@kas1e
Thanks!

@Capehill
Definitely sounds like yet another Nova bug. Did you check older (like 1.68) Nova versions? The reason I ask is because IIRC "Spencer" uses FBOs with float texture targets for its shadow effects; this at least worked at some point in the past (at least <= 1.68). So maybe this problem is something new? Unfortunately the latest "fixes" in more recent Nova versions increased the register demand even more to levels so high that "Spencer", among much other stuff, doesn't work anymore at all, obviously because of the generally broken register management
Also, because it has a similar smell as that other recent bug, did you disable mipmapping for those textures?
Anyway, please mail me what you got, if possible with src like the last time.

@Daytona675x

Good idea, tested with 1.68 also and problem was already there. I didn't see any filtering impact in this case.

http://www.amiga.org/developer/bugreports/view.php?id=610 (test binary)

Let me know if you still want to check the sources.