mirror of
https://github.com/bearstonem/openmohaa-vr.git
synced 2026-10-23 15:00:26 +02:00
bearstonemandClaude Opus 5
27011bd3eb
renderergl1 on gl4es runs on the headset at 90fps and draws the engine's own geometry - the intro logo screen renders under a flat colour override. The main menu still draws nothing, and that is the one open problem. The largest blocker turned out to be the gl4es build itself: with CMake's flags it cleared framebuffers perfectly and rendered no geometry whatsoever, measured as 144 red from a clear and 0 green from a quad into the same buffer moments later. Matching RTCWQuest's Android.mk fixed it outright with no engine-side change. gl4es's own CMakeLists adds -DANDROID under the NDK toolchain and ndk-build never does, so the reference has only been exercised without it, and it gates the code that decides what the fixed function pipeline may emit. Recorded at length because it invalidated most of a session's work: while gl4es could not draw, every experiment ending "and nothing was drawn" returned the same answer whatever it was testing. Four changes were adopted on the strength of such results and are now marked for re-testing rather than trusted. The document says plainly which findings are measured and which are not. Also commits the framebuffer helpers the VR layer needs: gl4es has to own the GL_FRAMEBUFFER binding or it renders from its own table into a 16x16 pbuffer, while the swapchain texture attachment and the blit's read and draw bindings must stay with the driver - routing those through gl4es empties the blit and takes the cutscenes with it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>