Live data from Hacker News

What's new in C# for Godot 4.0

godotengine.org

111–112 of 112 posts

Re: What's new in C# for Godot 4.0

#111
post #109
post #42

Earlier quoted context omitted.

Sorry but that makes no sense. Here are quotes from the C#/.NET group director at unity about how the migration to CoreCLR should bring a large perf boost: "One thing that should help in the future is the migration to CoreCLR that should provide a great boost in terms of performance."[1] "What we have seen, outside of Unity, is that performance with CoreCLR compared to Mono should range from 2x to 10x faster." [2] [1…

"outside of Unity"

Because unity is not yet on CoreCLR. But unity shouldn‘t be much different to other applications. Jetbrains moved Rider only a few years ago to .NET Core, and everything became much snappier (it was on on .NET 4.x on windows and on mono for Linux/Mac before, which was even slower than the windows only full framework)

Re: What's new in C# for Godot 4.0

#112

Earlier quoted context omitted.

It's mostly a historical accident, like Python ending up as the data science language. Microsoft XNA used to be a popular indie game framework that used C#. Stardew Valley, Celeste and Terraria run on XNA. Mono used C#. Xamarin used Mono to create a cross-platform application framework that worked on mobile. Unity leveraged Xamarin to create a cross-platform game engine that worked on mobile, ending up using C#. Thus…

I don't see this at all. game devs on average want to be closer to the hardware and JS is even farther from it than c# (and c# has added more ways to do things like traditional pointers when you need to squeeze even more performance out). Lua you can certainly make an argument for because LuaJIT is insanely fast.

aseo is right, of course, but even with game engines it depends on the game. Modern hardware is fast enough that you can get away with a lot. Minecraft used to be written in Java, 2D games that aren't Dwarf Fortress can be written in practically anything.

If you're an indie dev you usually don't want to strain the hardware with extremely complex models and textures and rendering pipelines, because you don't have the money to produce or source these models and textures.

Post reply on HN