Hacker News Reader

Comment by bartwe | Hacker News Reader

My last 8 yrs of game development have been in a good part about how to make c# go fast, and it is definitely possible, but you will have to write in a style that is different from the norm.

View on HN

Before C and C++ became widely acceptable for game development, we used to read these bibles like these,

https://www.jagregory.com/abrash-black-book

https://www.amazon.com/PC-Intern-Encyclopedia-Programming-De...

https://www.amazon.com/Black-Art-Game-Programming-High-Speed...

Very little regular C and C++ code, plenty of inline Assembly.

Can you please elaborate on that, or provide some links?

A few other commenters hit the points better, but mostly it comes down to avoiding allocating objects every frame/tick. In part this is through avoiding LINQ, lambdas, yield return, async etc. (fine to use in code that is run once like startup, or on relatively rare triggers) Using struct, arrays of struct/value, Span<>, ref, fixed etc. to keep memory access sequential or on stack. Use mutable structs, avoiding properties, avoiding struct constructors, moving throws into utility methods, etc. to support (the rather weak) optimizer to do more inlining. And move data processing of arrays of struct with tight loops, like compression, lighting, meshing, pathfinding into a native c++ dll/so or if applicable gpu. (c++ autovec/simd optimizations or much better than what the clr optimizer currently provides)

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++?

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.

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

However not every single game out there is trying to fit Shadow of the Colossus into a PS 2 or XBox 360.

Reply on news.ycombinator.com