spoopyghosty0 8986aa7040 FrameBridge: answer xrGetDisplayRefreshRateFB with the real rate (PreyVR black menu, #306) ...

The Frame's runtime has no XR_FB_display_refresh_rate (-7); OVRPort's dispatcher still
offers it and answered 0 Hz. Team Beef's idTech 4 ports run USERCMD_MSEC = 1000 / refresh,
so PreyVR had 0 ms tics: the async thread spun (~1.9M tics/s), com_frameTime stayed 0 and
the main menu's timeline never got past its first step (black backdrop + cursor only).
FrameBridge now always answers with 1 / predictedDisplayPeriod (else the refresh_rate
setting, else 72 Hz). Headless: menu drawn (snapshot mean 68 vs 0.1 before), clocks advance.

- glmv: gl_mv_debug=2 traces draws (state, GL errors per framebuffer), failed texture
  uploads/copies/compiles and idTech 4 clocks; how this was found
- triage: a single xrEndFrame -16 is info, not the black-menu error it was blamed for
- PLAYBOOK row, CLAUDE.md fact, host test for the fallback rate

2026-10-17 02:19:00 -04:00

..

glmv_rewrite.h

frame.gl_multiview_fbo: single-view twins for multiview programs drawn into flat framebuffers (GitHub #77)

2026-10-09 10:54:40 -04:00

glmv.c

FrameBridge: answer xrGetDisplayRefreshRateFB with the real rate (PreyVR black menu, #306)

2026-10-17 02:19:00 -04:00