mirror of
https://github.com/bearstonem/openmohaa-vr.git
synced 2026-10-24 14:00:23 +02:00
bearstonemandClaude Opus 5
bec1f4a8d5
Firing in the Bocage multiplies roughly a sixth of the screen down by about 4x for as long as the trigger is held. It is the ground plane, with hard polygon edges, and it is not black - the texture is still there underneath. r_worldDlights 0 in autoexec.cfg stops the world responding to dynamic lights at all, which loses flashes lighting the scenery and is the smaller loss. The cause is not found. Seven theories were tried and all seven were wrong, so what this mostly commits is the evidence, in docs/markdown/04-coding/05-dlights.md next to the gl4es notes, so that picking it up again does not start from nothing: the cadence table and the frame difference that measured the 4x, a table of every dead theory with what killed it, the worked texcoord arithmetic showing the faces land correctly, and the one hard contradiction to resume on - every component of the dynamic lightmap path measures correct end to end, and switching the path off makes the symptom stop. Two things in there are recorded specifically because they look damning and are not. "texels 9275" against "rows 28" cannot fit, but R_RealDlightFace counts c_dlightTexels before it knows whether any light landed and then bails at !added without committing to dli.allocated, so failed surfaces are counted and take no space. And R_UploadDlights' guard on tr.pc.c_dlightSurfaces reads like it must always be zero from the back end, because R_IssueRenderCommands clears the counters before running the command list - it is not what happens, measured at 35 surfaces. That guard is gone anyway: the height below it is the same test done against the allocator's own state rather than against a debug counter. The workaround is its own cvar rather than a level of vr_traceDlight, which is what it was while it was being tested. A diagnostic switch that also changes behaviour means turning tracing off silently brings the bug back, and this port has already lost a day to a cvar that did not do what its name said. The diagnostics stay, off. 1 reports what each upload contained and where every dlit face landed in the atlas; 2 stains the whole atlas white and paints the lit texels magenta, which is read off the walls rather than out of the log; 3 skips ProjectDlightTexture, which was measured never to run here and is kept because proving that cost a run. The first stain was dark green and was useless in a level made of hedgerows - white can only brighten, so it cannot be mistaken for foliage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>