Shaderjoy 1.27

@Capehill
Ok, investigated. There was indeed a separate endian bug in Mesa’s float texture uploads, which I fixed, but Shaderjoy’s issue is unrelated.

Shaderjoy creates its FBO textures with unsized GL_RGBA as the internal format and GL_FLOAT as the data type. Mesa accepts the texture
creation, but rejects that combination as a framebuffer attachment. The framebuffer stays incomplete, and clearing it produces GL error 1286.
I reproduced the same behaviour with a small test on WSL2/Linux Mesa, so this isn’t specific to our OS4 port.

Daniel’s Ogles2 accepts this usage, but OES_texture_float doesn't guarantee that these textures can be rendered into. Mesa currently rejects
it, so the question is whether we want a compatibility change in Mesa or an adjustment in Shaderjoy ?

For 32-bit float buffers, the supported Mesa route is an ES3+ context with GL_EXT_color_buffer_float and an explicit GL_RGBA32F internal format:



The external GL_RGBA and GL_FLOAT arguments stay the same + apply the internal-format change to both initial allocation and resizing.

Or, if we want to stay with ES2, use 16-bit half-float buffers, after checking for GL_OES_texture_half_float and GL_EXT_color_buffer_half_float:



But half-float suck, has lower precision and range and will affect some shaders.

I can make Mesa accept the existing allocation, but that would be a thing we need to maintain separately always,
and fixing Shaderjoy to use the supported allocation may be better way. What you think ?

@kas1e

I will try to fix the float issue, thanks for looking into it.

@Capehill

Thanks for the update and Mesa support!