61–70 of 98 posts
Earlier quoted context omitted.
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
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…
Earlier quoted context omitted.
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 Run…
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?
C# has been in the gamedev toolkit since XNA, over a decade ago.
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.
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 whe…
Earlier quoted context omitted.
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 whe…
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.
Does the GC in Unreal-mono have the same problems? If not, it's a non-issue.
Earlier quoted context omitted.
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 whe…
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.
Invoking the GC constantly on a frame by frame basis can quickly lead to heap fragmentation, resulting in pausing, because that is considered 'working against' the GC (both stop the world and concurrent). This is where custom solutions, such as pooling, should be used to mitigate these issues.
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…
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.
A mixed C/C++ callstack is so benign and common that it likely won't even register as being a "multi language" debugging experience. You get a single unified stack display, breakpoints, the works. There's a caveat or two around exceptions - that's about it. Everything just works.
C#/C++ isn't quite as solid, but it's still ahead of Python/C++ IME. Namely, Visual Studio will again show you a single unified callstack. There are more warts - again involving exceptions, as well as crash dumps and after the fact debugging. I've occasionally needed to break out WinDbg to deal with this.
Python/C++ is a bit harder. If you don't have a debug engine that can unify callstacks, however, there's still stuff you can do - dumping out both C++ and Python callstacks (and possibly locals) programmatically on assertions and in crash handlers, for example. I've done this for Java/C++, ActionScript/C++, Squirrel/C++, and probably more that I've forgotten.
"Own scripting language"/C++ is harder still: you must build your own everything. Debug engines are big projects - I haven't even completed my standalone one for brainfuck. If you dump your callstacks, you not only have to use the APIs that let you do so, but write them in the first place.
Earlier quoted context omitted.
Uh, what? C++ doesn’t have garbage collection. Did I misread this comment?
Still possible to have huge deallocations in C++. On top of that, C++ makes it possible to fragment memory, whereas .NET's GC can compact references. In both languages you have to be conscientious of types of allocations.
Building and using the tools to track down and break up circular references, dangling pointers, leaks, visualize memory fragmentation, etc. has eaten up a lot of my time.
I've considered attempting to write what would amount to a compacting GC in a C++ codebase to deal with memory fragmentation issues before - but retrofitting such a beast into an existing codebase was a huge enough undertaking, that we went for other simpler half measures instead. Being unable to control some middleware and system allocations meant any such GC would involve half measures and hacks as well anyways.