Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mono for Unreal Engine

mono-ue.github.io

Post reply on HN
Print view View original

51–60 of 98 posts

Re: Mono for Unreal Engine

#51

Post by andybak »

Ologn wrote: post #30
TazeTSchnitzel wrote: post #12

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?

If you download VR games, all the ones I have seen so far - that give credit - have been done with Unity. I know ones made with Unreal are out there, I have not download any with the Unreal logo yet though. I dabbled with the Daydream Google VR NDK C++ sample app and did a demo app for myself of simple shapes moving around. While I could do simple things, I couldn't imagine doing the type of games others have done on…

There's less Unreal based games for VR than Unity but some of the most graphically impressive titles are based on Unreal. Robo Recall for example.

Valve's The Lab plumped for Unity because of the state of Unreal's forward renderer at the time but they wrote their own renderer. This was fair while back and both engines have moved on since then.

Re: Mono for Unreal Engine

#53

Post by ljmeijer »

carussell wrote: post #38
thehardsphere wrote: post #29

Earlier quoted context omitted.

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,…

Ola, Lucas from Unity here,

Xamarin and Unity never did a renewed licensing deal. That doesn't make the lovely xamarin people nor us jerks :)

Licensing issues aside, for an ecosystem like Unity to upgrade its runtime, c# language, and base class libraries is an enormous undertaking. While we are not perfect, we take backward compatibility very seriously. All of mono and coreclr has been available under MIT licensing for a very long time now. In Unity2017.1 we now ship an experimental option to use modern .net. this uses a new mono (not using sgen), new c# compiler (still mcs for now, so c#6, not c#7, and .net4.6 class libraries).

In a future unity version (won't burn my fingers on exactly which one) this new .net experience will become default. (depends on how many problems you find! :)

the xamarin (and microsoft .net) team are wonderful folks, and it's great to work closely with them to make .net in unity, and .net in general solid.

next up on the list is improving the garbage collection story, which is in the works, but we're first focussing on shipping a new runtime+c#+.net base class libraries.

While there are some very valid areas to point out that make c# challenging to be "the language of an entire game", we believe that c# is a great controlling language for Unity. We're working on some really interesting (imho) compilation pipeline for a restricted compute subset of c# that I think will completely turn around people's expectations and opinions of c# in gaming. stay tuned, this is one of the most interesting projects happnening inside of Unity today.

Re: Mono for Unreal Engine

#54

Post by hacker_9 »

thehardsphere wrote: post #21
TazeTSchnitzel wrote: post #12

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 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.

Pros:

1. The GC provides a huge time-saving net over a ton of possible memory errors. Not to mention the code is so much easier to read when you aren't having to deal with memory on every line.

2. The debugging experience is brilliant - because there is always metadata available, you can literally inspect everything.

3. Compilation time is super fast.

4. Code samples are available for pretty much everything. And when there aren't, you can always interop into C++ or whatever else.

Cons:

People unfamiliar with the language forget about the GC and let it do all their dirty work. They then get angry when it bites back because of all the allocations they are doing each frame. The answer is to use pooling, and structure your code in a way that works with the GC (not against it), and all these problems go away.

Re: Mono for Unreal Engine

#55

Post by migueldeicaza »

mwkaufma wrote: post #27
thehardsphere wrote: post #21

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.

Unity 5.x only uses Mono for the editor. On non-Windows platforms they use their own AoT .Net implementation, IL2CPP.

The code generator is indeed different, the runtime is still Mono.

Mono today has two code generators: Mono's built it one, and an LLVM one. Both generate code after Mono loads and processes the assembly.

Unity developed a different front end to the runtime that does the compilation from IL to C++, the result still requires the Mono runtime to provide services at execution time.

They are currently upgrading their Runtime and are making a version with all the greatest features available coming.

Re: Mono for Unreal Engine

#56

Post by migueldeicaza »

carussell wrote: post #50
oblio wrote: post #41

Earlier quoted context omitted.

Shouldn't this stop being an issue under Microsoft's patronage? .NET definitely doesn't have a stop-the-world garbage collector and this should trickle to Mono, if it hasn't already.

Here's Miguel's blog post from a couple years ago (before the Microsoft acquisition) when their cooperative mode GC first landed: http://tirania.org/blog/archive/2015/Dec-22.html

That effort continues, we have an update in Mono's blog and we are about to share details on our next concurrent/parallel milestone soon.

Re: Mono for Unreal Engine

#57

Post by atomicrat2552 »

danbolt wrote: post #40
nialo wrote: post #22

Earlier quoted context omitted.

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.

Unity is just now updating the runtime for the first time in seven years. I think only the 2017.x releases have the new Mono, and most platforms use their IL2CPP AoT compiler I believe

Re: Mono for Unreal Engine

#58

Post by migueldeicaza »

danbolt wrote: post #40
nialo wrote: post #22

Earlier quoted context omitted.

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.

We are collaborating with Unity to assist on upgrading not only their runtime but also to adopt the latest and greatest GC.

Additionally in C# 7, 7.1 and the upcoming 7.x series there are many improvements that reduce object allocation (like ref structs, value type tasks and others)

Re: Mono for Unreal Engine

#59

Post by migueldeicaza »

ljmeijer wrote: post #53
carussell wrote: post #38

Earlier quoted context omitted.

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,…

Ola, Lucas from Unity here, Xamarin and Unity never did a renewed licensing deal. That doesn't make the lovely xamarin people nor us jerks :) Licensing issues aside, for an ecosystem like Unity to upgrade its runtime, c# language, and base class libraries is an enormous undertaking. While we are not perfect, we take backward compatibility very seriously. All of mono and coreclr has been available under MIT licensing…

Just want to say, working with Unity and their team is a delight.

And they have given great feedback on the future of the language and framework that Microsoft is going to fully embrace to make Unity users happy.

Hugs and love Lucas!

Re: Mono for Unreal Engine

#60

Post by org3432 »

Drakim wrote: post #46
org3432 wrote: 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.

Wouldn't it be roughly like when games embed Lua?

I think the difference would be that UE is used more in AAA games that have high performance requirements, which can be non-trival.

You can see an example of troubleshooting lock hitches using a 3rd party tool to get an idea of the complexity. https://www.youtube.com/watch?v=RE04LQffZfs

Post reply on HN