In reply to jwz.

I have a spare one I don't need.

However there are approximately 931 other android devices you would need to validate GLES transferring functionality for.

In reply to Jacob White.

Bool is not the problem. Also glColor is the branch that works.

In reply to jwz.

I threw this into android studio to try it on an android phone, and it seemed to want Bool changed to bool, and glColor3f changed to glColor4f. Other than that it worked. Maybe something like a macro would do the trick without too much work?

#define glColor3f(r, g, b) glColor4f (r, g, b, 1.0f)

In reply to jwz.

Get with the program, grandpa, nobody does that any more.  They vibe code the new version (which somehow is now two million lines instead of 500,000) at the small cost of the extinction of a few lesser species and thirty pieces of silver handed to a plutocrat.

Several hundred thousand lines of the shiny new implementation turn out to be a bug-ridden implementation of Common Lisp except the only data type is the string and there is no garbage collector. Several hundred thousand more are an interpreter for the language the previous version was written in for this misbegotten Lisp.  The remainder is an insecure web client which downloads the original source.

It's all for the best.

In reply to jwz.

For the record, I didn't (mean to) suggest the latter.

Anyways, apparently some of the newer hardware chips dropped support for OpenGL ES, in particular the Exynos chips used in many Samsung devices.  The shaders still work in snapdragon chips.

I don't know if you pick an android CPU or phone model to emulate, but other than that I've got nothing further to add via my colleague. Good luck.

In reply to the vessel of morganna.

Apple works fine, it's only Android that is being weird.

In reply to Jacob White.

Already there.

EGL config ID:     0x02
EGL caveat:        none
EGL conformant:    0x45 GLES-1.x GLES-2.0 GLES-3.0
EGL buffer type:   RGB
EGL red size:      8
EGL green size:    8
EGL blue size:     8
EGL alpha size:    8
EGL depth size:    24
EGL buffer size:   32
EGL stencil size:  8
EGL native type:   0x3038
EGL render type:   0x45 GLES-1.x GLES-2.0 GLES-3.0
EGL surface type:  5
EGL buffer width:  32767
EGL buffer height: 32767
EGL buffer pixels: 1073676289
EGL max swap:      10
EGL min swap:      1

In reply to Christopher Hylarides.

"The API you've been using for 30 years has been 'deprecated'" is not news to me, and "You should 'just' rewrite your ~500,000 lines of existing code to use the New Hotness instead" is a "go piss up a flagpole"-level suggestion.

In reply to Christopher Hylarides.

I tried GL_COLOR_MATERIAL, that doesn't help. All that does is implicitly call glMaterial with the prevailing glColor value.

In reply to Christopher Hylarides.

I don't have an actual Android device and never will, but I am told that it also fails there.

In reply to Christopher Hylarides.

He 's also telling me that modern mobile development has mostly replaced GLES fixed function pipelines with programmable shaders that compute lighting/texturing/blending yourself (again, this is all over my head).  Everybody seems to be moving away from OpenGL.  Vulkan, Metal, and probably now WebGPU are where things are going and platforms like react native for cross platform work are becoming the norm. :-/

In reply to Christopher Hylarides.

This is over my head as I've never done 3D anything, but he sent me this:

That translation layer likely has one of these bugs:

1. It computes alpha through the full lighting equation instead of just taking d_material.a. The default emission material is (0, 0, 0, 1.0) -- if emission alpha leaks into the computation, the result clamps to 1.0 and you get fully opaque output regardless of what you set on diffuse/ambient.
2. GL_AMBIENT_AND_DIFFUSE doesn't propagate the alpha to the internal diffuse slot correctly, so the diffuse alpha stays at the default 1.0.

iOS works because Apple's native GLES-to-Metal path is a different and more "correct" implementation on metal.

He recommends maybe trying to use GL_COLOR_MATERIAL:

glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
glEnable(GL_COLOR_MATERIAL);   // current color tracks ambient+diffuse material

glColor4f(c1[0], c1[1], c1[2], c1[3]);  // sets material, including alpha
glDrawArrays(GL_TRIANGLES, 0, 6);

glTranslatef(0.5, 0.25, 0);
glColor4f(c2[0], c2[1], c2[2], c2[3]);
glDrawArrays(GL_TRIANGLES, 0, 6);

But he also says he doesn't envy you and this is one reason he now does mobile development for the financial industry and not game development (the other being all mobile games are now pay-to-win hellscapes).

Does it work on an actual android device?  My mobile developer colleague says that the emulation layers when developing android on Mac often don't translate GLES cleanly and bugs are common.

In reply to jwz.

the tl;dr version is: Apple considers OpenGL deprecated and no longer natively supports it. On current macOS/iOS, OpenGL calls are implemented via translation to their proprietary graphics API, Metal.
Further complicating things, the Android emulator implements GLES by way of another translation layer called ANGLE. Both Apple's GL{,ES}/Metal translation as well as ANGLE are known to have weird bugs like this, and based on the GL_VERSION you reported it's possible that *both* translation layers are in use here, making debugging an absolute nightmare.
i'm sorry I don't have much more to offer, the only Apple device I have on hand atm I can't use for testing.

In reply to the vessel of morganna.

Sad to report that I understood none of that....

What happens if you add
EGL_ALPHA_SIZE,   8,
to attribs[] ?

In reply to jwz.

sorry, my question wasn't very clear. I also answered it from looking at Apple's docs - *all* GL/GLES versions are wrapped on top of Metal these days. I had some suspicion that the GL/GLES<->Metal wrapper was at fault, but that same wrapper is going to be present in your native iOS environment.
I do wonder if the Android simulator is still using ANGLE, and if it is, whether it's translating to Metal directly or if your stack ends up being the simulator<->ANGLE w/ GL4.1 backend<->Apple's wrapper<->Metal. lots of potential for API translation problems with more than one wrapper :

In reply to the vessel of morganna.

If you mean my gl to gles library, it is not involved. These are native calls.

is the same code running natively on iOS also using the same OpenGL-on-Metal translation layer?