How to read a Bachata S4 compatibility report
A green badge is only the start. The useful part of a compatibility report is the exact release, device, driver, game version, settings, evidence, and date behind it.
PS4 emulation on Android combines several moving parts: the emulator release, x86-64 guest execution, the Android device's CPU and GPU, Vulkan behavior, the selected graphics driver, the game's own update, and the phone's thermal limits. Because any one of those can change an outcome, Bachata S4 stores reports as configuration-specific observations instead of publishing a single permanent “works” or “doesn't work” verdict.
1. Start with the status, but do not stop there
Playable means the tester found the title suitable for normal play in that recorded configuration without a major blocker. Ingame means controllable gameplay was reached, but important issues can remain. Menus means the title reached a menu or title screen without verified gameplay. Boots means startup produced meaningful visual or audio output before an early blocker. Nothing covers a crash, hang, black screen, or other failure that did not produce a useful runtime result.
2. Match the emulator release and commit
Emulators change quickly. A renderer fix can improve one game while exposing a regression in another. Before comparing your result with a report, use the same Bachata S4 release when possible and check the exact commit if it is recorded. If the report was created several releases ago, treat it as historical evidence rather than the expected behavior of the current build.
3. Compare the device, SoC, and GPU separately
A phone model is useful, but the underlying SoC and GPU are often more informative. Two devices sold under similar names can use different chips in different regions. Even two phones with the same SoC can differ because of cooling design, memory pressure, firmware, power management, and vendor Vulkan components. The database therefore keeps the device label, SoC, GPU, Android version, and graphics driver as separate fields.
4. Treat the graphics driver as part of the test
On supported Adreno devices, a Mesa Turnip build can behave very differently from the system Vulkan driver. Driver names such as “Turnip” are not enough by themselves: the exact version or build matters. A rendering bug seen on one build may already be fixed in another, while a newer driver can also introduce a regression. When you reproduce a report, match the driver type, version, and build before changing emulator settings.
5. Read FPS as a measurement, not a promise
Average FPS describes the recorded measurement window. It does not automatically mean the whole game runs at that speed. Menus, cutscenes, small indoor scenes, and large outdoor scenes can have very different workloads. Short tests can also finish before a phone reaches its sustained thermal state. When minimum and maximum FPS, frame-pacing notes, resolution scale, and test duration are present, read them together.
For example, a 30 FPS average can still feel poor if frame times are unstable, and a short 45 FPS sample can fall after several minutes of thermal throttling. Performance comparisons are most useful when the game scene, test duration, device temperature, resolution scale, and driver are close.
6. Check the game version
Game updates can change executable code, shaders, asset layouts, and runtime behavior. A report against the base disc version may not reproduce on a later patch. If the database records a game version, match it before assuming the emulator itself caused a difference.
7. Use screenshots to understand what “works” means
A screenshot can prove that the title reached a particular scene and can reveal rendering defects that a status badge cannot describe. Missing geometry, corrupted textures, lighting errors, UI problems, or color-space issues may still be visible even when gameplay is technically reachable. The permanent game pages keep screenshots next to the exact report that produced them so evidence is not detached from its configuration.
8. Use logs to separate symptoms from causes
A black screen can come from very different failures: guest-code execution, missing system functions, shader compilation, Vulkan synchronization, audio initialization, filesystem access, or a game-specific assumption. Sanitized logs are valuable because they let developers distinguish the visible symptom from the subsystem that failed. If you submit a new result, attach logs from the same session as the screenshots and status you report.
9. Compare report history before calling something a regression
Every CUSA page preserves multiple reports rather than overwriting the previous one. If an older release is Playable and a newer release is Ingame, first compare device and driver changes. If the environment is materially the same, the difference is stronger evidence of a regression. If the device, driver, game version, or settings changed at the same time, more testing is needed before attributing the difference to the emulator release.
10. Reproduce with the fewest changes possible
When troubleshooting, change one variable at a time. Start from the closest published report, match the release and driver, then compare your result. Only after that should you vary the driver, resolution scale, or other settings. This produces useful evidence and avoids a situation where several simultaneous changes make it impossible to know which one mattered.
What makes a useful new report?
A strong report names the exact CUSA serial, game version, Bachata S4 release and commit, phone model, SoC, GPU, Android version, selected driver, relevant emulator settings, test date, observed status, performance measurement, and the specific issues seen. Screenshots and sanitized logs should come from that same configuration. The testing methodology explains the review process, and the contact page points to the correct GitHub location for reports and corrections.