Skip to content

reXact-fps v0.4

Latest
Latest

Choose a tag to compare

View all tags
@Retzilience Retzilience released this 23 Dec 12:16
· 11 commits to main since this release
0.4
26352c0
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

reXact-fps v0.4

Downloads

What this is

reXact-fps is a timing and responsiveness testbed.

It allows you to control the simulation step rate (Engine FPS) and the presentation rate (Visual FPS) independently, while moving a cursor using either a controller stick or the mouse. The intent is to make differences in responsiveness, stepping, interpolation, and presentation behavior visible and comparable.

What it’s useful for

  • Comparing how different engine update rates feel, independent of rendering rate
  • Observing how low engine rates introduce stepping and latency even when visuals are smooth
  • Understanding what interpolation changes visually, and what it does not
  • Comparing behavior across different displays, sync modes, drivers, compositors, and OS setups
  • Testing perceived input lag and smoothness in practice rather than theory

The same Engine FPS / Visual FPS values can feel different depending on the full pipeline from input sampling to display update.

Core concepts

Engine FPS vs Visual FPS

  • Engine FPS
    Fixed-step simulation rate. Input becomes part of the simulation only on engine steps.

  • Visual FPS
    How often frames are rendered and presented.

If Visual FPS exceeds Engine FPS, multiple frames may show the same simulation state unless interpolation is enabled.
If Engine FPS exceeds Visual FPS, the simulation may advance several steps between frames; fewer frames are shown, but each frame reflects a more recent state.

Real-time reticle vs simulated dot

  • Reticle: best-effort “right now” view of input
  • Glowing dot: simulated state, updated only on engine steps

In controller mode, the reticle is integrated at render time from the latest stick values. When Engine FPS is low (or the engine cannot keep up), the reticle can move ahead of the simulated dot. This separation is intentional and visualizes fixed-step latency and stair-stepping.

Mouse mode and polling

In mouse mode, the simulation samples the mouse position once per engine step and snaps the simulated dot to it. This means the input sampling that matters to the simulation is gated by Engine FPS, even if the OS cursor and display update smoothly.

Interpolation

Interpolation affects rendering only.

When enabled, the rendered glowing dot is blended between the previous and current simulated positions based on how far the main loop has progressed into the next engine step. This reduces visible stepping when Visual FPS exceeds Engine FPS, but does not change when input becomes simulation.

The reticle is not interpolated by this toggle, and the target is drawn at its simulated position for clarity and stability.

Examples that tend to show differences clearly

  • Engine 120 / Visual 60 often feels more responsive than Engine 60 / Visual 120, despite the latter presenting more frames.
  • Higher engine rates incorporate input more frequently.
  • Higher visual rates with lower engine rates can look smoother, but responsiveness remains gated by engine steps.

This also serves as a stand-in for frame insertion or frame generation: additional in-between frames can look smoother, but if they do not advance the simulation or incorporate new input, responsiveness does not improve in the same way.

Performance and limits

Maximum achievable Engine FPS and Visual FPS depend on the system and display pipeline. The application is lightweight (pygame), but very high resolutions or very high target rates may not be attainable.

If a desired Engine FPS is not being reached, setting Visual FPS very high or to 0 (uncapped) can help raise the pacing ceiling and make it easier to see what the simulation can actually sustain.

On-screen Engine and Visual rates reflect what the program actually achieves, not the requested values.

Distribution

This release is built with Nuitka, which translates Python modules into C and compiles them with a native compiler while bundling the CPython runtime. In practice, this reduces overhead and typically runs faster than executing the same code directly with the Python interpreter.

Controls

  • Shift — Toggle the main HUD
  • Ctrl — Toggle mouse mode
  • I — Toggle interpolation
  • Esc — Close dialogs / exit
  • Mouse wheel / PgUp / PgDn — Scroll in dialogs

Notes

  • Visual FPS = 0 means uncapped presentation
  • Measured rates reflect actual achieved performance

License

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)

Non-commercial use only. Derivative works and redistributions must credit the original project and creator and must be shared under the same license.

Assets 4
Loading