mirror of
https://github.com/bearstonem/openmohaa-vr.git
synced 2026-10-23 18:00:26 +02:00
bearstonemandClaude Opus 5
e967529ec6
gl4es answers glGetIntegerv for GL_CULL_FACE_MODE, GL_FRONT_FACE and GL_MODELVIEW_MATRIX out of its own tables (src/gl/getter.c), the same way it answers glGetString from constants - the trap section 5.5 already records. Two measurements in this session read back "GL" state through qgl, compared it against the engine, found it identical, and concluded the state was correct. They were comparing the engine against gl4es's copy of the engine. That agrees by construction and proves nothing, and both conclusions drawn from it were worthless. It matters because gl4es also drops calls its cache thinks are redundant - glCullFace returns early when the mode already matches (src/gl/face.c:14), as do glDepthMask, glDepthFunc, glBlendFunc, glColorMask, glScissor and glViewport. So the driver can hold something the engine never asked for while gl4es reports the engine's own value straight back at it. r_traceSurf now resolves glGetIntegerv and glIsEnabled out of libGLESv3 directly and prints the driver's answer next to gl4es's. The open question it is aimed at: world geometry disappears with backface culling enabled whichever face is named, while CT_TWO_SIDED models are unaffected. No winding fault does that, but a driver cull mode of GL_FRONT_AND_BACK would, and gl4es would still report GL_FRONT. Not tested on the device. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>