3 ms·
Not an expert, but the version of it that I've heard is your main game loop handles all interaction with the game state to avoid issues. You can offload renderi
by wlesieutre 9y ago
Not an expert, but the version of it that I've heard is your main game loop handles all interaction with the game state to avoid issues. You can offload rendering into another thread pretty safely, and anything that alters game state would queue up its state changes for batch processing.
That way if you're running a multithreaded physics simulation you can get two separate bullet collision detections on one object, and instead of trying to delete the object twice you put both "kill this thing" actions on a to-do list. When it comes time to handle that in the main loop, you sweep through it for conflicts before executing any of the changes.
UE4 in particular I know handles all game logic in a single thread, and you can't touch UObjects from outside of that. But here's an example (without much technical detail) of someone implementing multithreaded pathfinding for UE4: https://forums.unrealengine.com/community/work-in-progress/11929-rama-s-multi-threaded-dynamic-pathing-system-full-physics-support https://forums.unrealengine.com/community/work-in-progress/1...
- iainmerrick 9y agoUE4 in particular I know handles all game logic in a single thread, and you can't touch UObjects from outside of that. Yeah, that's the kind of thing I was thinking of when I said games programmers seemed skeptical of threads. Some of that coarse-grained parallelism could possibly be done in JS with Web Workers, but those have their own problems. (See the recent discussion here about the "tasklets" proposal: https://news.ycombinator.com/item?id=15511519 https://news.ycombinator.com/item?id=15511519)