Sylpheed RE agent 8e63a95425
Some checks failed
Orchestrator / Lint (push) Failing after 1m49s
Orchestrator / Commit Message Validation (push) Has been skipped
Orchestrator / Windows (x86-64) (push) Has been skipped
Orchestrator / Linux (x86-64) (push) Has been skipped
Orchestrator / Create Release (push) Has been skipped
[RE] file-pad: opt-in Keystroke REPEAT, at the SDL driver's own constants
The instrument behind the F1 menu-repeat measurement. It was uncommitted for
a day while the numbers it produced were already shipping in the port.

The file driver deliberately emits exactly one event per press -- repeat is
what makes scripted menu steps overshoot -- so it structurally could not show
whether the GAME repeats a held direction. Measured through it, a held (down)
moved the cursor once and never again, at any hold length. That is a property
of the driver, not of the game, and the page that recorded it said so.

`--pad_file_repeat` opts in, off by default, so no existing script changes.
It reuses the SDL driver's Waiting/Repeating state machine and its constants
VERBATIM (HID_SDL_REPEAT_DELAY=400, HID_SDL_REPEAT_RATE=100, guest-time ms)
rather than re-deriving them -- the point is to be a fair stand-in for a real
controller, and a re-derived constant would only measure our own arithmetic.

With it, the cursor cycled the whole 5-item menu for as long as the button
was held: 19 distinct positions, 12 frames to the first repeat, 4 frames
between the rest, at 29.87 fps guest.

⚠️ The 4-frame interval is NOT the 100ms constant that drives it (100ms is
~3 frames). The game consumes drained keystrokes at its own per-frame pace.
The 400ms delay, by contrast, comes back as 402ms -- that confirms the
instrument, not the game.

docs/re/f1-repeat-measured-via-driver-patch.md in the Sylpheed repo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-13 19:17:17 +02:00
2026-03-27 11:17:55 +09:00
2025-11-20 03:53:43 -08:00
2025-11-20 03:53:41 -08:00
2025-11-20 03:53:41 -08:00

Xenia Canary - Xbox 360 Emulator

Xenia Canary is an experimental fork of the Xenia emulator. For more information, see the Xenia Canary wiki.

Come chat with us about emulator-related topics on Discord. For developer chat join #dev but stay on topic. Lurking is not only fine, but encouraged! Please check the FAQ page before asking questions. We've got jobs/lives/etc, so don't expect instant answers.

Discussing illegal activities will get you banned.

Status

Buildbot Status Releases
Canary (🪟, 🐧) CI Codacy Badge LatestAllOld

Experimental Netplay

Buildbot Status Releases
Windows Codacy Badge Latest

Quickstart

See the Quickstart page.

FAQ

See the frequently asked questions page.

Game Compatibility

See the Game compatibility list for currently tracked games, and feel free to contribute your own updates, screenshots, and information there following the existing conventions.

Building

See building.md for setup and information about the xb script. When writing code, check the style guide and be sure to run clang-format!

Contributors Wanted!

Have some spare time, know advanced C++, and want to write an emulator? Contribute! There's a ton of work that needs to be done, a lot of which is wide open greenfield fun.

For general rules and guidelines please see CONTRIBUTING.md.

Fixes and optimizations are always welcome (please!), but in addition to that there are some major work areas still untouched:

See more projects good for contributors. It's a good idea to ask on Discord and check the issues page before beginning work on something.

Disclaimer

The goal of this project is to experiment, research, and educate on the topic of emulation of modern devices and operating systems. It is not for enabling illegal activity. All information is obtained via reverse engineering of legally purchased devices and games and information made public on the internet (you'd be surprised what's indexed on Google...).

Description
No description provided
Readme BSD-3-Clause 71 MiB
Languages
C++ 97.8%
Python 1%
CMake 0.4%
GLSL 0.2%
HLSL 0.2%
Other 0.2%