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

71–80 of 98 posts

Re: Mono for Unreal Engine

#71

Post by org3432 »

pmalynin wrote: post #61
org3432 wrote: post #60

Earlier quoted context omitted.

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

Crysis & CryEngine used LUA so I don't think the AAA argument makes sense.

UE didn't go that route as you'll notice though, that was one of the reasons if I'm remembering correctly.

Re: Mono for Unreal Engine

#72

Post by kevingadd »

socialist_coder wrote: post #66
kuschku wrote: post #65

Earlier quoted context omitted.

But that's not the issue - any other GC'd language has a much faster and better GC than this ancient mono version. That was the issue mentioned.

Yes, and that complaint is specific to Unity's current GC. They will update it eventually, and it will no longer suck. Does the GC in Unreal-mono have the same problems? If not, it's a non-issue.

Unity has a specific situation with Mono that doesn't apply to anything else. It won't apply here, something like this can use the latest Mono.

Re: Mono for Unreal Engine

#73

Post by kevingadd »

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.

This isn't Unity. Why does Unity's version of Mono matter here?

Re: Mono for Unreal Engine

#74

Post by tracker1 »

socialist_coder wrote: post #66
kuschku wrote: post #65

Earlier quoted context omitted.

But that's not the issue - any other GC'd language has a much faster and better GC than this ancient mono version. That was the issue mentioned.

Yes, and that complaint is specific to Unity's current GC. They will update it eventually, and it will no longer suck. Does the GC in Unreal-mono have the same problems? If not, it's a non-issue.

It should be significantly better, but can still pause. Beyond this, it really depends on how you are allocating/using/reusing objects... There are techniques you can use that aren't too painful to overcome some of the issues.

Re: Mono for Unreal Engine

#75

Post by tracker1 »

0xFFC wrote: post #44

A little bit unrelated, but serious question. Mono and .net core are not going to converge? I mean that would be awesome. Since most of game developers nagging about Mono's bad performance

They're not strictly converging, but there is ever increasing code reuse where it makes sense. Mono supports a lot more in the box than .Net Core currently does. I could see a point where .Net Core covers as much as Mono does within reason, and the rest of Mono eventually becomes separate packages in Nuget.

But wouldn't expect that in under 3-5 years. Just an observer from the sidelines.

Re: Mono for Unreal Engine

#76

Post by WillPostForFood »

thehardsphere wrote: post #18
BoorishBears wrote: post #17

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?

Unreal C++ has garbage collection: https://wiki.unrealengine.com/Garbage_Collection_Overview

Re: Mono for Unreal Engine

#77

Post by WillPostForFood »

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?

Tim Sweeney gave a good explanation why they went C++. Seems reasonable, but I'll be happy to see C# support.

https://forums.unrealengine.com/showthread.php?2574-Why-C-fo...

- As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.

- As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or "interop" layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.

- Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.

- Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can't trace the C++ that code led to it, and vice-versa.

Re: Mono for Unreal Engine

#78

Post by joveian »

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.

I hope so, although I particularly hope that more game designers build games such that the windows distribution can be directly run by mono on not-windows. That is the way the game is most likely to stay working for an long time and under multiple operating systems. I'm no fan of Microsoft, but compatibility over time is one thing they do better than anyone else and games are the one kind of application where that is particularly important. Plus Mono is excellent. There are other ways game designers could try to make their applications more likely to work for a long time, but in practice they don't do that.

I haven't noticed garbage collector related issues with mono, although I don't play the type of games where that would be most noticible. I have seen a number of games with memory leaks that require a restart after a while, but that is the case under windows as well. I've recently stopped buying Daedalic games because they can't manage to make a simple adventure game with almost no movement work on a system with 4GB memory, but they are by no means the only ones with this problem.

C# on top of C++ might not help that much other than encouraging more game designers to use C#.

Re: Mono for Unreal Engine

#79

Post by clock_tower »

b0rsuk wrote: post #52
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?

Sounds suspiciously like Embrace, Extend...

Microsoft's sponsoring Mono now, and they've always been pretty benevolent towards game companies, especially with how seriously they take backwards compatibility. I wouldn't worry too much, at least not at this point.

Re: Mono for Unreal Engine

#80

Post by Mikeb85 »

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?

> Is C# becoming the lingua franca of modern game engines?

Unfortunately. It's a decent language, but it just seems a bit too heavy to use as a scripting language, but not as good as C++ for heavy lifting.

I'm doing some stuff on Godot, and will probably just end up using GDScript for basic stuff, and GDNative for more intensive stuff (It's a C/C++ API for shared libraries that you can load up through the editor).

Post reply on HN