4 ms·
"The existing C++ client is too much of a mess to make concurrent; people looked at it and gave up" 99,9% of games that you describe are built in C++, it works
by Thaxll 6y ago
"The existing C++ client is too much of a mess to make concurrent; people looked at it and gave up"
99,9% of games that you describe are built in C++, it works fine. Modern engines are doing that without much troubles.
- aaron_m04 6y agoEvery C++ project is different. Maybe this one was poorly architected.
- Animats 6y agoThe original implementation is 20 years old. Some very good people designed it, but it's from the era when computers came with one CPU and GPUs didn't do much. C++ programs tend to be heavily inheritance oriented, with huge lists of includes and inheritance. Decoupling things to parallelize them is very difficult in that environment. Rust is mostly a single assignment language with move semantics, which encourages creating objects (yeah, the Rust crowd calls them structs) and passing them off to something else in a somewhat functional style. So you get programs that are less tightly coupled. That's useful if you find you want to pass an object to another thread, put it on a queue, etc. for performance reasons. Any dangling pointers or cross-thread references will be caught at compile time. That alone makes development far easier.
- pjmlp 6y agoAlthough not perfect, assuming all source code is available, clang and visual c++ checkers can do similar checks. So it is always a matter of equating the value of a full rewrite and how well the checkers are able to provide valuable feedback. Which I concede Rust will be much better, however then there is the whole loss of ecosystem to also consider.
- frankzinger 6y ago> clang and visual c++ checkers can do similar checks. > Which I concede Rust will be much better, Aren't these two statements contradicting each other?
- krferriter 6y agoA lot of games slam the CPU even when idle because of busy waiting and looping they built into the game which could likely be improved by better async and parallelization natives or frameworks.
- Too 6y agoThis is common for many real time applications, not just games. It can be a result of designing for WCET (Worst case execution time). By always running on worst case even if not needed, your testing becomes much easier because there is less need to go into every corner case and see if your frame rate drops. For gaming its less of a safety issue but it gives a more consistent experience. Games also really don't care since they are single use applications. You are not going to run something else cpu intensive in the background while playing.
- issamehh 6y agoThat seems like quite a bold assumption about what I'll be running. While I do expect to a game to be able to take what it needs and certainly that could be a lot, I've definitely ran multiple games or ran intensive software at the same time. It's not always so simple
- deleted 6y ago[deleted]