mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-10-14 15:00:30 +02:00
Henrik RydgårdandClaude Opus 5
333d84935e
--disable-hle had no counterpart, which made "is this our fault or the game's?" awkward to answer: the only ways to put our HLE back were a per-game config or hiding the firmware, and neither works from a script - the setting is per-game and the firmware gets found anyway. --force-hle takes the same bitmask and runs our HLE for those libraries even where the real module is now the default, so the same repro can be run both ways and the logs diffed. Used it on the warnings left over in Tekken 6 under the real mpeg.prx. Three of them appear identically with --force-hle=16, so they are the game's own and match what the hardware answers: sceKernelChangeThreadPriority(-1) eight times in a row (pspautotests/threads/threads/change says hardware returns UNKNOWN_THID for -1 too), sceAtracAddStreamData on a released id with a zero byte count, and a sceKernelDeleteMutex on a garbage id. The fourth only happens under the real module and is ours. mpeg.prx sizes its allocation through a scratch context in its own bss and calls sceAudiocodecReleaseEDRAM on that one, while decoding through a different context that never gets released - so the next movie's sceAudiocodecInit finds a live decoder and replaces it. That is once per video on every game running the real module, and it was a WARN_LOG_REPORT, so it would have reported from everyone's machine. It is bounded - removeDecoder deletes the old one and Init makes exactly one more - so it is an INFO_LOG now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>