Live data from Hacker News

Mono for Unreal Engine

mono-ue.github.io

31–40 of 98 posts

Re: Mono for Unreal Engine

#32

C# is Unity's main programming language, now there's this for Unreal, and Godot 3.0 will also have C# support. Is C# becoming the lingua franca of modern game engines?

I don't think so. If I remember it correctly, the Epic guys said something about switching back (for the Unreal Engine 4) from their own scripting language to C++, because multi language debugging was a nightmare, and working on a big Python/C++ project myself, I can comfirm this.

Re: Mono for Unreal Engine

#33

Earlier quoted context omitted.

C# has value types, it takes some careful coding to avoid GC stutters, but imo not nearly as careful as C++

Uh, what? C++ doesn’t have garbage collection. Did I misread this comment?

The engine makes uses of shared pointers to do ref counting, and will deallocate unrefed objs for you. Additionally there is a built in asset GC system.

Re: Mono for Unreal Engine

#34
Would be interesting if the author could comment on the memory footprint and performance of having an additional GC'ed language running alongside the engine. It seems like it could lead to complex hitching issues.

Re: Mono for Unreal Engine

#35
post #34

Would be interesting if the author could comment on the memory footprint and performance of having an additional GC'ed language running alongside the engine. It seems like it could lead to complex hitching issues.

I can guess: Too many cooks, spoil the broth! :)

Re: Mono for Unreal Engine

#36
post #24

Earlier quoted context omitted.

The version of Mono that is shipped with Unity is bad specifically for licensing reasons, there is no technical cause.

What's wrong with the licensing? Not disagreeing with you; this is just the first I've heard of it.

It's just a really old version.

Re: Mono for Unreal Engine

#37
post #32

C# is Unity's main programming language, now there's this for Unreal, and Godot 3.0 will also have C# support. Is C# becoming the lingua franca of modern game engines?

I don't think so. If I remember it correctly, the Epic guys said something about switching back (for the Unreal Engine 4) from their own scripting language to C++, because multi language debugging was a nightmare, and working on a big Python/C++ project myself, I can comfirm this.

Arr, the inevitable defeat by the core languages performance boost- lets allow for pointers to arrays in the core language, to not loose speed. The locks and non-locks, the fun of value changes while some variable holds part of a array in local memory of the script languages maschine, the problem of external data corupption, without having everything under assert all the time aSSERT(Not NaN, Not Infinity). Plus, the script languages garbage collection, making a custom allocator necessary- allmost like the one you allready have written. On and on it goes. If it where not for the artists ease of use and fast iteration, nobody would use the script languages.

Re: Mono for Unreal Engine

#38
post #24

Earlier quoted context omitted.

The version of Mono that is shipped with Unity is bad specifically for licensing reasons, there is no technical cause.

What's wrong with the licensing? Not disagreeing with you; this is just the first I've heard of it.

The popular telling of the story is that the team behind Mono asked for too much money to allow the Unity3D team to have a commercial license exception to newer versions of Mono.

(This comes from the Unity team's explanation to the Unity community about why their runtime remains out of date. It's since become a meme to paint the Mono folks as a bunch of jerks over this. This endured for a few years. In the meantime, however, Microsoft has released .NET under permissive terms that would allow Unity to use Microsoft's own runtime royalty-free—no need for a commercial license exception. Despite the opportunity it presented, an upgraded runtime failed to materialize from Unity. Maybe the transition from Mono to .NET Core was too big of a leap? Fair point. Thing is, Mono itself is now also relicensed under MIT, by way of Microsoft's acquisition of Xamarin, so Unity is free to make commercial use of newer Mono versions on proprietary platforms, just like Unity always wanted. Still, no upgrade to the Unity runtime.)

Re: Mono for Unreal Engine

#39
post #19

Earlier quoted context omitted.

For 'lightweight logic' maybe, but using GCed language for almost all logic executing every frame is bad idea.

Just because it's GC'd doesn't mean it's constantly allocating memory. Optimizing the most common heap allocation sources isn't very difficult (especially compared to the nightmare of manual memory management). I recommend running the Roslyn Clr Heap Allocation Analyzer extension for VS for a few days - it helps to learn which language features and APIs implicitly allocate objects (or box value type objects). Plus, m…

I wrote games and engines in C++ for 15 years, and Unity for about 5. I strongly prefer manual mem management, hands down. Optimizing for Unity's GC, in pathological situations, is the nightmare.

If the game is relatively simple, and the heap relatively small, it's not a big problem. But if you're trying to make a large, complex simulation that's actually pushing boundaries, the GC becomes a constant adversary. People always talk about allocations, but not allocating during a frame is just the minimum price of admission. The real trouble is the static characteristics of the heap, like size and graph complexity. With manual alloc, at least the problem is straightforward: don't leak, and don't dangle. With a black-box GC, where you can't even hint to it about the lifetimes of objects, you have to be much, much more aware of memory management, then go through a lot of different non-idiomatic contortions regarding every single thing you put on the heap.

Re: Mono for Unreal Engine

#40
post #22

Earlier quoted context omitted.

I would certainly hope not. C# implementations are terrible for lots of games on not-Windows. The version of Mono that has been included with Unity is particularly bad with respect to stop-the-world garbage collection pauses.

Do you know if this is still true with the newer "concurrent" garbage collector in more recent Mono versions? I work on an audio player app rather than games, but also have problems with the GC in Mono on IOS. We're hopeful that eventually they'll go away, but haven't tried again recently.

I'm willing to bet that Mono GC has improved a lot, but I don't think that Unity frequently updates the runtime. It's kind of painful, from what I've been told.
Post reply on HN