3 ms·

Also you can check games like quake, doom etc which have opened their source, they are all done like that.

by popotamonga 6y ago

mojuba 6y ago
Doom and Quake were created in the single-core era. I was just wondering if modern game design is different.
- dan00 6y ago
  Here is a talk from the developer Naughty Dog - making big games on the Playstation - about the parallelization of their engine: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug.... Having a system thread for every entity in a game doesn’t scale. Also having to synchronise the threads of entities by hand would be quite a nightmare. It scales a lot better to have a thread pool, with a thread for each core, and then running lightweight jobs on them. So pretty much the same idea like e.g. the goroutines in Go or the green threads of Erlang. Having such a job system you also have a lot less hassle with thread synchronisations. I’m working on an interactive 3d application and the job system we’ve have works like a charm for parallelization.
  - mojuba 6y ago
    Thanks, that's very interesting. The benefit of threads - green or not - is also that you can maintain the state in the stack and benefit from functional style programming, which is generally more robust and easier to write compared to state machines. Parallelism has many forms and from my experience you can always find ways of minimizing synchronization in particular tasks. For example, you can sometimes replace a whole queue with a single atomic pointer when you know messages override previous ones semantically, i.e. the consumer is only ever interested in the most recent one.
- rcxdude 6y ago
  Here's an interesting presentation on Overwatch's ECS system, though he doesn't go into great detail in terms of multithreading, he points out how the design makes it easy to identify what parts of the system can be safely run in parallel. https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw

Also you can check games like quake, doom etc which have opened their source, they are all done like that.

mojuba 6y ago

Doom and Quake were created in the single-core era. I was just wondering if modern game design is different.

dan00 6y ago
Here is a talk from the developer Naughty Dog - making big games on the Playstation - about the parallelization of their engine: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug.... Having a system thread for every entity in a game doesn’t scale. Also having to synchronise the threads of entities by hand would be quite a nightmare. It scales a lot better to have a thread pool, with a thread for each core, and then running lightweight jobs on them. So pretty much the same idea like e.g. the goroutines in Go or the green threads of Erlang. Having such a job system you also have a lot less hassle with thread synchronisations. I’m working on an interactive 3d application and the job system we’ve have works like a charm for parallelization.
- mojuba 6y ago
  Thanks, that's very interesting. The benefit of threads - green or not - is also that you can maintain the state in the stack and benefit from functional style programming, which is generally more robust and easier to write compared to state machines. Parallelism has many forms and from my experience you can always find ways of minimizing synchronization in particular tasks. For example, you can sometimes replace a whole queue with a single atomic pointer when you know messages override previous ones semantically, i.e. the consumer is only ever interested in the most recent one.
rcxdude 6y ago
Here's an interesting presentation on Overwatch's ECS system, though he doesn't go into great detail in terms of multithreading, he points out how the design makes it easy to identify what parts of the system can be safely run in parallel. https://www.youtube.com/watch?v=W3aieHjyNvw https://www.youtube.com/watch?v=W3aieHjyNvw