mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-03 11:15:20 +02:00
--launch starts PPSSPP itself, learns the debugger port from its output, connects once the socket accepts, and kills it on exit. That replaces some wrapper scripts, which had to background the emulator, poll a log file for "Listening on port N", sleep a guessed interval before connecting, and taskkill afterwards. The polling was also racy - a fixed port plus a leftover process from an earlier run is a good way to drive the wrong emulator - and nothing cleaned up, so --timeout's wall-clock budget left processes alive for hours. To make that dependable, the port is now also written straight to stderr from Core/WebServer.cpp, outside the log system entirely. A tool that launches PPSSPP has to learn the port before it can connect to anything, so that line must not be losable to a log level or a disabled channel. wsdbg watches both child streams for it, since which one it lands on depends on how a given build routes logging. --quiet sends the broadcast.config.set that every script was hand-writing, disabling the logger and input broadcasts. The log one is expensive - each line gets encoded as JSON and pushed down the socket. The rest is one bug, in the docs rather than the code, which cost a lot of time: the scripting example paired cpu.runUntilTime with ":wait cpu.stepping". --sync already waits for the cpu.stepping that follows a resume-family command, so the explicit :wait waits for a second one that never comes and burns the whole --sync-timeout. With --sync-timeout 400 that turns a 3-second run into a 7-minute one that looks exactly like a slow boot, because the emulator really has stopped where it was asked to. Example fixed, and both that and muting the 'stepping' category (same failure, different cause) are called out - wsdbg now warns when a raw broadcast.config.set disables 'stepping'. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9