INSANE IMPROVEMENTS on low-end CPUs: up to 4x more FPS
i3-9100F class CPUs: from 19-32 FPS to 97-120 FPS. Dual cores: about 3x faster.
Test build for low-end CPUs (issue #209, also #148, #157, #191, #285, #319, #330, #333, #387). If your CPU sat at 100% while your GPU was nearly idle, and lowering the resolution did nothing, this build is for you.
What was wrong
The game spreads its work over 5 worker threads that wait for jobs with a busy spin lock. On a PS4 each of them has its own core, so that spin lasts nanoseconds. On a PC with 4 threads or fewer, Windows pauses the worker holding the lock and the other ones spin for their whole time slice. They took almost all the CPU, leaving the thread that feeds the GPU with about 17% of one core: CPU at 100%, GPU at 15%, 16 to 30 FPS.
What changes
- Worker threads run at a lower priority (below normal on Windows, nice +5 on Linux). They still get every idle cycle, but they can no longer starve the GPU thread and the game's main thread. No setting needed.
- Sound thread runs at a higher priority: the game's sound driver (and its file I/O threads) had a high priority on PS4 but ran at normal priority here. With 4 threads the sound output ran dry 113 times a minute on 2.6.0, with gaps up to 92 ms (crackles and stutters). Now: 0 times, gaps under 10 ms. On Linux the priority is only raised when the system allows it.
- CPU report per thread in
last_run.log: when the game closes normally, the log lists the threads that used the most CPU (Runtime: CPU time by thread) and how often threads yielded while waiting. If you still have low FPS, this tells us where the time goes. - Everything else is the 2.6.0 build. The launcher still shows v2.6.0 and does not offer this build as an update.
Measured results
Test machine: AMD Ryzen 5 5600X (6 cores / 12 threads) + Radeon RX 6700 XT, Windows 11. Each CPU below was simulated by limiting the game to the same number of cores and threads (Windows CPU affinity, set before the game starts). Same scene every time (Gaia's head, Poseidon fight area). "Before" is the 2.6.0 behaviour, "After" is this build, compared live in the same session. FPS read from the in-game overlay.
| Simulated CPU | Cores / threads | Affinity | Before | After | Gain |
|---|---|---|---|---|---|
| Intel Core i3-9100F (also i5-7400, i5-6500, i5-4440, i5-3470) | 4 / 4 | 0x55
| 19 to 32 FPS | 97 to 120 FPS | about 4x |
| Intel Core i3-2100 / i3-3240 | 2 / 4 | 0xF
| 27 to 30 FPS | 65 to 86 FPS | about 2.5x |
| AMD A4-5300 / Athlon X2 340 | 2 / 2 | 0x5
| 14 to 16 FPS | 40 to 48 FPS | about 3x |
| AMD Ryzen 5 5600X (no limit) | 6 / 12 | all | 133 to 150 FPS | 133 to 160 FPS | no change |
| Single core | 1 / 1 | 0x1
| 3 FPS | 5 FPS | not playable |
With 4 threads, GPU usage went from 18% to 60%, and the GPU thread from 37% to 66% of a core.
Frame time and sound with 4 threads (30 to 45 seconds each):
| 2.6.0 | This build | |
|---|---|---|
| Frame time, 99th percentile | 106 to 175 ms | 37 ms |
| Frame time spread (standard deviation) | about 30 ms | about 6 ms |
| Sound ran dry | 113 times per minute | 0 |
| Largest gap in the sound | 92 ms | 9 ms |
Tip for weak CPUs: the CPU is still almost full, so some frames take 30 to 60 ms. Set the engine frame rate to 60 FPS in the launcher for a steadier picture.
Your numbers will be lower than these: the simulation uses fast Zen 3 cores, and older CPUs are slower per core. The gain should be in the same range. CPUs without MOVBE/BMI (Sandy and Ivy Bridge, like the i3-3240 and i5-3470) also pay for the instruction rewrite, which this build does not change.
Strong CPUs (6+ threads, like the Ryzen 5 5600G or 5700G in #157 and #333) see no change here: their limit is a different one, the single GPU command thread. That is the next step.
How to test
- Extract
spartanport-windows.zipover your currentspartanport-windowsfolder (this keeps your saves, settings and shader cache). - Play as usual for at least 5 minutes, ideally a place where your FPS was low before.
- Close the game from the in-game menu (not with Alt+F4 or Task Manager), so the CPU report is written.
Reply on #209 with: your CPU, GPU, resolution, FPS before and after (the in-game overlay shows it: Insert > Overlay), whether the sound stuttered, and user/last_run.log.
Validation so far
- Built on Windows 11 (MSYS2 CLANG64), full Python suite run on the development branch.
- Played on a Ryzen 5 5600X + RX 6700 XT limited to the CPUs in the table above, with live A/B of the old and new behaviour in the same scene.
- Sound and frame time measured with the game's own statistics (
SPARTAN_AUDIO_STATS,SPARTAN_FRAME_STATS) at 4, 2 and 12 threads. With 2 threads the sound still ran dry 6 times in 30 seconds: the CPU is completely full there. - Not checked yet: loading times and a real low-end CPU, and the Linux build (not compiled).
SHA-256: see spartanport-windows.zip.sha256.
You still need your own copy of the game files. No game files are included.