mirror of
https://github.com/spoopyghosty0/frameport.git
synced 2026-10-23 06:01:38 +02:00
spoopyghosty0
8986aa7040
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
16 lines
730 B
C
16 lines
730 B
C
// SPDX-License-Identifier: GPL-3.0-only
|
|
// Display refresh rate for xrGetDisplayRefreshRateFB when the runtime doesn't give one (session_fixes.c). Pure, so the
|
|
// host test (tests/fixtures/src/refresh_rate_test.c) can check it.
|
|
#pragma once
|
|
#include <stdint.h>
|
|
|
|
// The rate the frame timing shows (1 / predictedDisplayPeriod of the last xrWaitFrame, whole Hz), else the
|
|
// refresh_rate setting, else 72 Hz (the Frame's rate for Android apps).
|
|
static inline float fb_refresh_rate(int64_t display_period_ns, float setting) {
|
|
if (display_period_ns > 0) {
|
|
double hz = 1e9 / (double)display_period_ns;
|
|
if (hz >= 30.0 && hz <= 240.0) return (float)(int)(hz + 0.5);
|
|
}
|
|
return setting > 0 ? setting : 72.0f;
|
|
}
|