megboyzzandClaude 1a74432c48 Add an opt-in glViewport probe; settles task #52 (0.8 render scale, not a bug)
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>
2026-09-19 17:34:23 +03:00
2025-09-05 18:38:01 +03:00
2025-09-05 18:38:01 +03:00
2025-09-05 18:38:01 +03:00
2025-09-05 18:38:01 +03:00
2025-09-05 18:38:01 +03:00
S
Description
Мод добавляющий мультиплеер для NFSMW
17 MiB
Languages
C++ 48%
Java 46.1%
Kotlin 4.4%
C 1%
Shell 0.3%
Other 0.2%