A Xiaomi 14 capture showed viewport 2136x960 against a 2670x1200 surface and
raised the question of whether the engine was feeding the game a wrong size -
the shape of task #39, where the UI projection used 2000x1000 instead of the
real 2400x1080.
Logging each DISTINCT viewport with its bound framebuffer and the real EGL
surface size answers it. Pixel 6a:
VIEWPORT [0,0 2400x1080] fb=0 | EGL surface 2400x1080 <- screen, exact
VIEWPORT [0,0 1920x864] fb=3 | EGL surface 2400x1080 <- an FBO
VIEWPORT [0,0 512x512] fb=1 | EGL surface 2400x1080 <- another FBO
The default framebuffer matches the surface exactly; the smaller viewport is
an offscreen target. And the ratio is decisive:
Pixel 6a 1920/2400 = 0.80 864/1080 = 0.80
Xiaomi 14 2136/2670 = 0.80 960/1200 = 0.80
Exactly 0.8 on both devices and both axes - the game's own render scale,
drawing the 3D scene into a reduced FBO and upscaling while the HUD stays at
full resolution. Nothing is broken; the engine reproduces it faithfully.
The probe stays in the tree behind kLogViewportChanges (default off, per the
standing rule that diagnostics are opt-in), because "which framebuffer was
bound" is exactly the context whose absence made the original observation
ambiguous.
Co-Authored-By: Claude <noreply@anthropic.com>
megboyzzandClaude
1a74432c48