2 ms·
> Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. Is that it doesn't be
by mlindner 6y ago
> Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust.
Is that it doesn't benefit, or is it that the benefits are too hard to achieve given the nature of memory issues with games that like to have global state and are written in C++? A lot of games do a bunch of things every frame and then increment state. Those can all be parallelized as they only depend on the previous frame's state.
- andrewmcwatters 6y agoNo, it's that most people won't benefit from it. You can't just take any type of game logic and parallelize it either, since there are types of game logic that aren't just dependent on the previous frame. You may be wholly dependent on something that has just occurred earlier in the frame, but has not been networked to clients yet.
- dxuh 6y agoGames code is very often about objects interacting. Especially the expensive stuff (collision/physics and then probably AI). Games don't use global state, because they use C++ and everyone is so bad at programming, but because that's what fits the problem domain. Not to be condecending, but you should try making a game and see how well that parallelization idea of yours turns out.