How Bachata S4 Compatibility Testing Works

Why CUSA IDs matter

Every PlayStation 4 title has a product serial, called a CUSA ID (for example CUSA00900). The same game can have different CUSA IDs for different regions, and each CUSA ID can receive different game updates over time. Anchoring compatibility records to a CUSA ID keeps reports comparable: when you read that CUSA00900 reaches gameplay, you know exactly which product variant the tester used, in which region.

One canonical game record per CUSA

The compatibility database keeps one canonical entry per CUSA ID. Searching for the game always lands on the same record, no matter how many devices or releases have been tested. The canonical discussion lives in one GitHub issue per game (labelled game-report), and the issue's status label reflects the best confirmed result across all reports for that game.

Why multiple reports are preserved

Compatibility is not a single fact. A game can run differently on different releases, devices, and drivers — sometimes better, sometimes worse. Instead of overwriting an old result, the database keeps every report as immutable evidence and adds new superseding reports on top. The report history per game stays visible, so users can see how results improved or regressed over time, and reviewers can compare.

Release-specific compatibility

Each report is tied to one published Bachata S4 release with its exact commit. Testers must install the APK from that release (or prove a build matches that commit). A result on v0.1.6 says nothing about v0.1.7 — the database keeps the release tag and commit on every report so the comparison is explicit.

Recording the physical device

Reports record the physical device by manufacturer and model, plus the SoC (for example SM8750), the GPU (for example Adreno 830), and the Android version. Two phones with the same SoC can still behave differently because of cooling, firmware, and driver builds, so the exact model matters. Testers never publish private device identifiers such as the ADB serial.

System driver vs Turnip / custom drivers

Bachata S4 renders with Vulkan. The driver actually used makes a large difference, so every report records the driver type and source: the device's system Vulkan driver, Mesa Turnip, or another explicitly selected custom driver. For Turnip and custom drivers, the exact version and build (for example 26.3.0-devel, git-9c51ede50f) are mandatory — “Turnip” alone is not enough, because different Turnip builds behave very differently.

Screenshots and logs

Reports include screenshots captured during the test and compressed session logs (the Bachata application log and the shadPS4 session log). Logs are checked for private information before publication. Screenshots serve as visual evidence of what the tester observed; they are test evidence, not marketing material.

Performance measurement

When possible, testers record average FPS, minimum and maximum FPS, frame pacing, and session duration. A single frame or short session is never enough: performance data describes the whole tested session, including dips, stutter, and thermal behaviour.

Status definitions

The status of a report is the furthest state actually observed in the tested configuration:

• Playable — suitable for normal play in the tested configuration, with no major blocker found.
• Ingame — reaches controllable gameplay, but completion and full stability are not verified.
• Menus — reaches menus or title screens, but not controllable gameplay.
• Boots — starts and produces meaningful visual or audio output before an early blocker.
• Nothing — crashes, hangs, or fails to produce useful output in the tested configuration.

When the tester is uncertain, the lower status is chosen. Ingame is not Playable: gameplay that works in a short session can still crash later, and completion is never assumed from a single session.

Why one good scene is not enough

A single 60 FPS scene does not prove a game is fully playable. Rendering, audio, input, and game logic differ between areas; long sessions can expose crashes, memory problems, and thermal throttling. That is why reports record the furthest state reached across the whole session, list known issues, and keep the status conservative.

Why results can regress between releases

Emulator development is not a straight line. A release that fixes rendering for one game can change the shader pipeline, memory layout, or CPU translation for another. Because every report is pinned to a release and preserved in history, a regression is visible as a report with a lower status on a newer release — it does not disappear into a rewritten database.

How issue discussions work

Each game has one canonical GitHub issue in the Bachata S4 repository, reused for every device and release. The issue carries a status:* label with the best confirmed result, displays at least one representative gameplay screenshot, and hosts the discussion. The compatibility entry on this site links directly to that issue.

How evidence is reviewed before merge

Reports are prepared in a dedicated worktree of the compatibility repository and are not published until the tester confirms them. The workflow requires legally owned software only, an official release, complete environment recording, and immutable evidence. The repository's validator checks every report against the schema, and the canonical issue is updated with the confirmed result — including the representative screenshot and immutable commit URLs.

Contribute a report

If you have a legally owned game not yet covered, the full step-by-step workflow is documented in the public compatibility repository: .agents/skills/bachata-compatibility/SKILL.md.

Browse existing game discussions on the issue tracker.