1a74432c48bc8b287f3b355322989a5f3211f67f
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>
Description
Мод добавляющий мультиплеер для NFSMW
17 MiB
Languages
C++
48%
Java
46.1%
Kotlin
4.4%
C
1%
Shell
0.3%
Other
0.2%