Live data from Hacker News

What's new in C# for Godot 4.0

godotengine.org

101–110 of 112 posts

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

#101
post #55

Earlier quoted context omitted.

JavaScript doesn't have value types or operator overloading (also applies to Java) - this makes writing vector math pretty shitty imo - and you're working with vectors all over the place in games.

How does it help with vector math?

Operator overloading makes simple math cleaner, but that's just a nice to have.

The real kicker is value type semantics. You have two options with reference types : you can either do math in-place or allocate on each operation. First option is a huge foot gun because the ownership is unclear it's super easy to share references to something and update something unintentionally. And it can be hard to track down. Second option is super taxing on GC. And the overhead of going through reference for simple 3 float tuple (and object type info, etc.) is large - but for large arrays you can sort of work around it by primitive arrays. But that's like hand rolling assembly and you're supposedly using a high level language.

C# with structs and operator overloading is an ideal high level language for gamedev - most of the time it's really ergonomic and high level, but it has the tools to get down to memory layout control without it looking like disassembled code.

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

#102
post #85
post #77

Earlier quoted context omitted.

As a developer on one of larger Unity games - yes, there are paint points elsewhere. There are many pain points. The poor performance of Mono/IL2CPP is a significant one for us. We have a different game built on .NET (Core) and performance is significantly better. I also wouldn't call Unity's Mono 'heavily optimized' because they definitely trail behind standard Mono. Unity doesn't even support Mono's generational ga…

Out of curiosity what engine are you using that leverages .NET (core) ? Stride?

It's an engine written in C++ (not Unreal) that we've added C# scripting to. So it's in the same kind of situation as Unity where their engine calls from C# land need to be marshaled into calls to native code and back, which of course has overhead.

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

#103
post #57
post #55

Earlier quoted context omitted.

How does it help with vector math?

I would imagine operator overloading helps with vectors so you can do things like: public static Vector operator -(Vector a, Vector b) { Vector v = new Vector(); v.X = a.X - b.X; v.Y = a.Y - b.Y; return v; } So then you can just write: Vector result = myVector1 - myVector2;

Why not implement a method?

var result = myvector1.sub(myvector2)

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

#104
post #82
post #10

Earlier quoted context omitted.

Everyone who uses javascript has to write it in a superset language that has sane types, a (poorly implemented) standard library, and other features javascript lacks, and treat it like a batch of volatile chemicals because outside of its specific niche of scripting the DOM, javascript is a terrible, unstable language at best adequate for purpose, a necessary evil because the web doesn't support anything else (barring…

> so why not use a better language to start with? Perhaps consider that for many programmers, TypeScript is JavaScript, and TypeScript is that better language. I've put a decent amount of thought into using TypeScript for games because it allows for a flexible, expressive data model in a way that few other languages do. The performance might be a problem for some flavors of games, but I'm interested in discrete simul…

Typescript as its own thing, with real types, not compiling to JS or being limited to its semantics, I could get behind as a language for game scripting.

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

#105

Earlier quoted context omitted.

> best browser game engine > web export is completely broken > Godot with C# straight up has no web export Hmm, something is amiss here... They're already on RC5 and web export not working doesn't sound like the web platform is a focus of theirs. AFAIK, the web export being broken is not mentioned in "Known Issues" about V4 either.

Web Export for 4 is fine, just not with C#. That may be the same thing to some people, but there is a distinction.

No, it's not fine. It's broken on Chrome for macOS and freezes on startup for about 10-20 seconds. Has nothing to do with C#, this happens with GDScript, too. It's a known issue, has been discussed at length on Github (by myself as well) and there is no fix in sight at the moment.

I would consider that broken.

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

#106
post #83

Any godot programmers here. How is godot's support of games in the browser? 4 years ago I was deciding on a game engine to use. I considered it to unreal, Unity, and godot. I want to be able to build games that can be played on the web. I have many fond memories of the Flash game days. Distributing games over the web allows me to share games with people without the friction of installers, or App Store gate keepers, w…

We made https://rocketbotroyale.winterpixel.io in godot 3.5. ~ 20MB wasm binary, ~20MB game assets. We did however, have to do a ** ton of engine modifications to get the performance characteristics we needed on web, so mileage may vary depending on what you are actually building. But overall, 3.5 supports web very well. 4.0 is too unstable for us to use it yet, so jury still out on that one. But the absolute, most a…

Do you see any use cases to include WASI into your godot gaming support? Maybe midi music too.

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

#107
post #82
post #10

Earlier quoted context omitted.

Everyone who uses javascript has to write it in a superset language that has sane types, a (poorly implemented) standard library, and other features javascript lacks, and treat it like a batch of volatile chemicals because outside of its specific niche of scripting the DOM, javascript is a terrible, unstable language at best adequate for purpose, a necessary evil because the web doesn't support anything else (barring…

> so why not use a better language to start with? Perhaps consider that for many programmers, TypeScript is JavaScript, and TypeScript is that better language. I've put a decent amount of thought into using TypeScript for games because it allows for a flexible, expressive data model in a way that few other languages do. The performance might be a problem for some flavors of games, but I'm interested in discrete simul…

In don't know what you mean by discrete simulations but I would expect simulation games to be more performance intensive because of unbounded complexity vs say an FPS game.

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

#108
post #82

Earlier quoted context omitted.

> so why not use a better language to start with? Perhaps consider that for many programmers, TypeScript is JavaScript, and TypeScript is that better language. I've put a decent amount of thought into using TypeScript for games because it allows for a flexible, expressive data model in a way that few other languages do. The performance might be a problem for some flavors of games, but I'm interested in discrete simul…

In don't know what you mean by discrete simulations but I would expect simulation games to be more performance intensive because of unbounded complexity vs say an FPS game.

"Discrete simulations" are things like turn-based strategy games, roguelikes, and so on. You can think of it as "automated board games" in a lot of ways.

https://en.wikipedia.org/wiki/Discrete-event_simulation

In truth, I think V8 is almost certainly more than fast enough for real-time games (real-time in the gaming sense, not in the OS sense); Mono is fast enough for Unity, even, and Mono is creaky and slow, with a really poor garbage collector, on its best day. But for the stuff I'm interested in, I just don't care at all.

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

#109
post #42
post #36

Earlier quoted context omitted.

CoreCLR is not built for game, the fork from Unity is so there is little chance that CoreCLR is faster.

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"

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

#110
post #44
post #36

Earlier quoted context omitted.

CoreCLR is not built for game, the fork from Unity is so there is little chance that CoreCLR is faster.

This claim would make more sense if the Mono was heavily optimized specifically for games, which is not the case. CoreCLR is heavily optimized period

Exactly. For ASP.NET they also optimized latency heavily.
Post reply on HN