Not about multiplayer but still interesting. Dennis Gustafsson – Parallelizing the physics solver – BSC 2025 ▶ this video
in “The unlikely story of Teardown Multiplayer” · View on HN
Dennis Gustafsson – Parallelizing the physics solver – BSC 2025 on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2025–2026.
talk · advanced · evergreen
Dennis Gustafsson, creator of Teardown, presents how he parallelized the physics solver for an upcoming game, followed by a Q&A. The talk was given at the Better Software Conference 2025.
HN points to it as a practical example of solving a tricky multithreading problem, including using a spinlock to speed up a real-time physics solver.
“The following is an interesting talk where the author used a spinlock to speed up a real-time physics solver significantly.”
3 Hacker News comments link this video. Each one links back to its thread.
Not about multiplayer but still interesting. Dennis Gustafsson – Parallelizing the physics solver – BSC 2025 ▶ this video
in “The unlikely story of Teardown Multiplayer” · View on HN
As always: use standard libraries, profile, then write your own if the data indicates it's necessary. The following is an interesting talk where the author used a spinlock to speed up a real-time physics solver significantly. Dennis Gustafsson – Parallelizing the physics solver – BSC 2025 ▶ this video
in “Spinning around: Please don't – Common problems with spin locks” · View on HN
From my understanding this talk describes how he implemented a solution for a similar problem ▶ this video I'm saying if you're not writing multi-threaded code everyday, use a library. It can use atomics/locks but you shouldn't use it directly. If the library is designed well it'd be impossible to deadlock.
in “Futurelock: A subtle risk in async Rust” · View on HN