mirror of
https://github.com/bearstonem/openmohaa-vr.git
synced 2026-10-23 12:00:25 +02:00
bearstonemandClaude Opus 5
633221c57d
The gl4es work was in the tree but nothing had exercised it. Three things were
wrong, each hiding the next.
cmake/platforms/android.cmake forced BUILD_RENDERER_GL1 OFF and GL2 ON into the
cache. CACHE INTERNAL implies FORCE, so the -D on the command line was
overwritten on every configure and renderergl1 had never once compiled - the
build that appeared to succeed was a renderergl2 build with gl4es sitting unused
beside it. The renderer choice goes back to the top level options, which already
default the way this port wants.
gl4es's own CMakeLists points CMAKE_LIBRARY_OUTPUT_DIRECTORY at
${CMAKE_SOURCE_DIR}/lib, which under FetchContent is this project's source root,
so the artifact was written into the engine's source tree. It also builds itself
as libGL.so.1 after the fashion of a system OpenGL, and Android has no versioned
sonames - the package manager extracts only lib*.so out of an APK. Redirected
into the build tree as libgl4es.so and staged with the other APK libraries.
With that fixed renderergl1 does compile for arm64, but it would not have
rendered. Its entry points come from GLimp_GetProcAddresses via
SDL_GL_GetProcAddress, and on EGL 1.5 - which the Quest is - SDL asks
eglGetProcAddress first. The driver answers for every name OpenGL 1.x and ES
have in common, so glEnable, glBindTexture and eighty more would have bound to
Adreno while glBegin and glMatrixMode bound to gl4es. gl4es would then have been
batching geometry and tracking a matrix stack against calls the driver was never
told about. The renderer now resolves against the gl4es handle directly, and
calls initialize_gl4es since NO_INIT_CONSTRUCTOR is set. The extension string
had the same problem and the same fix: read through SDL it is the driver's ES
list, which names none of the desktop extensions the renderer asks after, so
GL_ARB_multitexture read as absent and the renderer would have quietly dropped
to one texture unit.
The VR layer keeps its own direct GLES linkage; only the renderer is moved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>