3 ms·

GC isn't a big problem for many types of apps/games, and most games don't care about memory safety. Rust's advantages aren't so important in this domain, while

by yyyk 1y ago

GC isn't a big problem for many types of apps/games, and most games don't care about memory safety. Rust's advantages aren't so important in this domain, while its complexity remains. No surprise he prefers C# for this.

seivan 1y ago
[dead]
palata 1y ago
Except that C# is memory safe.
foderking 1y ago
great summary
loeg 1y ago
Not just GC -- performance in general is a total non-issue for a 2d tile-based game. You just don't need the low-level control that Rust or C++ gives you.
- trealira 1y ago
  I wouldn't say it's a non-issue. I've played 2D tile-based, pixel art games where the framerate dropped noticeably with too many sprites on screen, even though it felt like a 3DS should have been able to run it, and my computer isn't super low-end, either. You have more leeway, but it's possible to badly make optimized 2D games to the point where performance becomes an issue again.
  - loeg 1y ago
    These are gross, macro-level design problems; not the kind of thing where C# vs C++/Rust makes any difference.
maccard 1y ago
Disagree on both points. Anyone who has shipped a game in unity has dealt with object pooling, flipping to structs instead of classes, string interpolation, and replacing idiomatic APIs with out parameters of reused collections. Similarly, anyone who has shipped a game in unreal will know that memory issues are absolutely rampant during development. But, the cure rust presents to solve these for games is worse than the disease it seems. I don’t have a magic bullet either..
- Rohansi 1y ago
  This is a mostly Unity-specific issue. Unity unfortunately has a potato for a GC. This is not even an exaggeration - it uses Boehm GC. Unity does not support Mono's better GC (SGen). .NET has an even better GC (and JIT) that Unity can't take advantage of because they are built on Mono still. Other game engines exist which use C# with .NET or at least Mono's better GC. When using these engines a few allocations won't turn your game into a stuttery mess. Just wanted to make it clear that C# is not the issue - just the engine most people use, including the topic of this thread, is the main issue.
- pornel 1y ago
  I'm shocked that Beat Saber is written in C# & Unity. That's probably the most timing sensitive game in the world, and they've somehow pulled it off.
  - neonsunset 1y ago
    There's another highly sensitive to timing game - Osu!, which is written in C# too (on top of custom engine).
  - maccard 1y ago
    GC isn't something to be afraid of, it's a tool like any other tool. It can be used well or poorly. The defaults are just that - defaults. If I was going to write a rhythm game in Unity, I would use some of the options to control when GC happens [0], and play around with the idea of running a GC before and after a song but having it disabled during the actual interactive part (as an example). [0] https://docs.unity3d.com/6000.0/Documentation/Manual/performance-disabling-garbage-collection.html https://docs.unity3d.com/6000.0/Documentation/Manual/perform...

by yyyk 1y ago

seivan 1y ago

[dead]

palata 1y ago

Except that C# is memory safe.

foderking 1y ago

great summary

loeg 1y ago

Not just GC -- performance in general is a total non-issue for a 2d tile-based game. You just don't need the low-level control that Rust or C++ gives you.

trealira 1y ago
I wouldn't say it's a non-issue. I've played 2D tile-based, pixel art games where the framerate dropped noticeably with too many sprites on screen, even though it felt like a 3DS should have been able to run it, and my computer isn't super low-end, either. You have more leeway, but it's possible to badly make optimized 2D games to the point where performance becomes an issue again.
- loeg 1y ago
  These are gross, macro-level design problems; not the kind of thing where C# vs C++/Rust makes any difference.

maccard 1y ago

Disagree on both points. Anyone who has shipped a game in unity has dealt with object pooling, flipping to structs instead of classes, string interpolation, and replacing idiomatic APIs with out parameters of reused collections. Similarly, anyone who has shipped a game in unreal will know that memory issues are absolutely rampant during development. But, the cure rust presents to solve these for games is worse than the disease it seems. I don’t have a magic bullet either..

Rohansi 1y ago
This is a mostly Unity-specific issue. Unity unfortunately has a potato for a GC. This is not even an exaggeration - it uses Boehm GC. Unity does not support Mono's better GC (SGen). .NET has an even better GC (and JIT) that Unity can't take advantage of because they are built on Mono still. Other game engines exist which use C# with .NET or at least Mono's better GC. When using these engines a few allocations won't turn your game into a stuttery mess. Just wanted to make it clear that C# is not the issue - just the engine most people use, including the topic of this thread, is the main issue.
pornel 1y ago
I'm shocked that Beat Saber is written in C# & Unity. That's probably the most timing sensitive game in the world, and they've somehow pulled it off.
- neonsunset 1y ago
  There's another highly sensitive to timing game - Osu!, which is written in C# too (on top of custom engine).
- maccard 1y ago
  GC isn't something to be afraid of, it's a tool like any other tool. It can be used well or poorly. The defaults are just that - defaults. If I was going to write a rhythm game in Unity, I would use some of the options to control when GC happens [0], and play around with the idea of running a GC before and after a song but having it disabled during the actual interactive part (as an example). [0] https://docs.unity3d.com/6000.0/Documentation/Manual/performance-disabling-garbage-collection.html https://docs.unity3d.com/6000.0/Documentation/Manual/perform...