Is GL_R supported ?

[kas1e]

Tried to port some demo : https://github.com/nhoudelot/wayang-by-cyberneticgenetics

Compiles fine, but on running i have erros from gl4es 👍

LIBGL: unsupported pixel format GL_R LIBGL: unsupported pixel format GL_R LIBGL: unsupported pixel format GL_R LIBGL: pixel conversion, anticipated abort LIBGL: swizzle error: (GL_R, GL_UNSIGNED_BYTE -> GL_RGBA, GL_UNSIGNED_BYTE)

[ptitSeb]

mmm, I thought GL_R was supported. I'll add it later, it's easy.

[kas1e]

Yeah, not that it's so much necessary, but have some more bits supported always good :) And demo pretty chillout one :)

[kas1e]

It can be me mixed things up maybe (like compiling with different versions of libpng), but probabaly it still should't cause unsupported pixesl errors in any way. Try to build on Pandora , maybe it will be different ? Build very easy, just alter Makefile a little bit

[ptitSeb]

Most GLES2 hardware support GL_EXT_texture_rg that add GL_RED and GL_RG support in hardware. Doesn't AmigaOS4 driver have this?

[kas1e]

Nope, this one not supported.. On Pandora/Pyra this supported ?

[ptitSeb]

Yes, it's supported there. Anyway, I'll the GL_R in the right place, but still, this extension is often used when using shader, as it allow to create texture with just 1 or 2 channels.

[kas1e]

I asked Daniel about adding this extension as well, just for future

[kas1e]

Ok no more GL_R errors, but still all black.. Is it the same for you ?

[ptitSeb]

It seems to be working for me (but I do have the GL_R support)

[kas1e]

Hm.. Maybe issue that i do not have GL_R support ..

[kas1e]

I probably need to run glsnoop on it, to see what happens (maybe i will see gl errors there, etc)

[kas1e]

Daniel were fast enough and add GL_R support to ogles2, and so i tried demo : but still black screen... I do grab glsnoop log, but it didn't looks bad (at lest i can't see errors there).. :

https://kas1e.mikendezign.com/aos4/gl4es/demoscene/wayang/wayang_glsnoop.txt

Seems it can be something about default states and co .. or maybe some shaders works wrong .. Did you test with new gl4es where case in gl4es for GL_R were added, or without ? Just want to be sure that if GL_R present, then gl4es go that route

[ptitSeb]

but it works for me. maybe some bigendian issue on a texture?

[kas1e]

Dunno.. Daniel says after log checking that the log shows only two calls to glTexImage2D and no GL_RED or GL_RG is being used at all, just std. GL_RGBA. So maybe not GL_R issue involved there ..

[ptitSeb]

are you sure the extension is recognised? you see it on gl4es initialization? you should see

LIBGL: Extension GL_EXT_texture_rg  detected and used

[kas1e]

Yeah. see what i have now:

3/0.Work:demos/wayang> wayang-by-cyberneticgenetics 
LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Oct  1 2022 10:49:19
LIBGL: Using GLES 2.0 backend
LIBGL: Using Warp3DNova.library v54 revision 16
LIBGL: Using OGLES2.library v3 revision 4
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Targeting OpenGL 2.1
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: Current folder is:Work:demos/wayang
LIBGL: Loaded a PSA with 1 Precompiled Programs
LIBGL: Hardware test on current Context...
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax  detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Subtract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer  detected
LIBGL: Extension GL_OES_element_index_uint  detected and used
LIBGL: Extension GL_OES_packed_depth_stencil  detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888  detected and used
LIBGL: Extension GL_EXT_texture_rg  detected and used
LIBGL: Extension GL_OES_texture_float  detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth  detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Max texture size: 16384
LIBGL: Max Varying Vector: 32
LIBGL: Texture Units: 16/16 (hardware: 32), Max lights: 8, Max planes: 6
LIBGL: Extension GL_EXT_texture_filter_anisotropic  detected and used
LIBGL: Max Anisotropic filtering: 16
LIBGL: Max Color Attachments: 1 / Draw buffers: 1
LIBGL: Hardware vendor is A-EON Technology Ltd. Written by Daniel 'Daytona675x' MьЯener @ GoldenCode.eu
LIBGL: GLSL 300 es supported
LIBGL: GLSL 310 es supported and used
LIBGL: Shuting down

3/0.Work:demos/wayang>  

[kas1e]

And as for texture : it uses libpng which works in other apps for sure .. hm strange.. stange that in glsnoop log we do not have any GL_R .. Maybe it recognized in gl4es , but didn't enables or something ?

[ptitSeb]

Well, the detection is here

In glsnoop, you should see some GL_RED (not GL_R)

[kas1e]

Checked, nope, no GL_RED.

Interesting info found, if i run demo and wait till end (on black screen), then on final scene i have that, check this out (strating from 5th second):

https://youtu.be/pDXlAa8i6WU

Looks like data loaded up fine, and textures too, just mess with GL (clear ? swapping ?)

[kas1e]

Btw, you compile it with png12 or png16 ?

[ptitSeb]

it's png16 on my side

[kas1e]

Tried with png16 - same, only that on running have warnings from libpng about incorrect sRGB profile, but that probabaly harmless