3 ms·

Ok, I see, thanks. Why then using C#/.NET at all if you have to do without many (most?) of the conveniences of this technology, and even have to consider to imp

by Rochus 5y ago

Ok, I see, thanks. Why then using C#/.NET at all if you have to do without many (most?) of the conveniences of this technology, and even have to consider to implement parts in C++ for performance reason? Why not directly e.g. C++?

pjmlp 5y ago
For the same reason that many C and C++ games were actually using them as high level macro processors full of inline Assembly a couple of decades ago. There are some conveniences that come with the technology and not every code path on the game engine is screaming for perfomance. If you are on the path for the ultimate performance like some console titles, the C and C++ code on those engines will be very alien to most developers as well, yet you don't seem many discussing that. Just on the subject, here is a talk I saw recently on the theme, "Beyond the Remake of 'Shadow of the Colossus': A Technical Perspective" https://www.youtube.com/watch?v=fcBZEZWGYek https://www.youtube.com/watch?v=fcBZEZWGYek However not every single game out there is trying to fit Shadow of the Colossus into a PS 2 or XBox 360.
bartwe 5y ago
Because the hot paths in the code are not the majority of the code. C# is (for me) much more productive to write than c++. More powerful refactoring tooling due syntax that is much easier for tooling to process. Powerful autocomplete, autorefactoring tooling. Easy code navigation due to easy to process syntax. The tooling also responds much faster, c++ refactoring tools seem to take a long time to process code. Big reduction in footguns/UB etc. Very quick iteration cycles, edit-and-continue in sub second, stop-edit-restart cycles in the low single second range. Very good debugging, objects are inspectable and editable, stacktraces reliable. Edit-and-continue makes for very quick probing of internal state. The c++ code is around 1% of LOC and 20% of cpu cycles, seems like a good balance. Bounds checking, lack of dangling pointers/use after free, removes a whole class of hard to debug bugs.

by Rochus 5y ago

pjmlp 5y ago

For the same reason that many C and C++ games were actually using them as high level macro processors full of inline Assembly a couple of decades ago. There are some conveniences that come with the technology and not every code path on the game engine is screaming for perfomance. If you are on the path for the ultimate performance like some console titles, the C and C++ code on those engines will be very alien to most developers as well, yet you don't seem many discussing that. Just on the subject, here is a talk I saw recently on the theme, "Beyond the Remake of 'Shadow of the Colossus': A Technical Perspective" https://www.youtube.com/watch?v=fcBZEZWGYek https://www.youtube.com/watch?v=fcBZEZWGYek However not every single game out there is trying to fit Shadow of the Colossus into a PS 2 or XBox 360.

bartwe 5y ago

Because the hot paths in the code are not the majority of the code. C# is (for me) much more productive to write than c++. More powerful refactoring tooling due syntax that is much easier for tooling to process. Powerful autocomplete, autorefactoring tooling. Easy code navigation due to easy to process syntax. The tooling also responds much faster, c++ refactoring tools seem to take a long time to process code. Big reduction in footguns/UB etc. Very quick iteration cycles, edit-and-continue in sub second, stop-edit-restart cycles in the low single second range. Very good debugging, objects are inspectable and editable, stacktraces reliable. Edit-and-continue makes for very quick probing of internal state. The c++ code is around 1% of LOC and 20% of cpu cycles, seems like a good balance. Bounds checking, lack of dangling pointers/use after free, removes a whole class of hard to debug bugs.