Xenko Game Engine 2.0 released

Amen brother. I think most perf problems in Unity games would go away if Unity updated their GC. It's definitely our #1 source of frame rate hiccups. Plus, it makes you write weird crappy code just to avoid GC allocations. Ugg =(

Are there plans to replace Mono with .NET Core?

At that point you've created a different language with different semantics.

I instinctively get that thought whenever I work with C#. It's really nice but would it kill them to at least offer simplistic memory management semantics?

1. If you follow its development you know the features and the design philosophy. What's your point? 2. I picked Unity because it's the most popular engine with an underlying GC.

Regardless of their GC implementation, in games you don't want opaque runtime behaviour, which a GC always introduces. This leads to weird workarounds in your code that nobody understands instead of having clear and explicit memory management.

IMO, 2ms is too much for strong macro support. Even if GC had 0 run-time cost I'd still rather use C++ since 99.9% of my code is creating memory structures of particular layout (I write graphics). To write the same code in a GC language I'd have to map memory to a file and then use the strong macro system to emulate native struct type from C++ :)

C# specifies the language, not the runtime. Apart from .NET and Mono, you can compile C# to cpp (what Unity does under the hood, btw).

> Also, it would mean I didn't have to use OOP to write games.

There are many instances where other programming paradigms are more usable - but in my experience, gameplay logic, specifically, maps very well onto classic OOP concepts.

You should take a look at what is going on in the latest dotnet core CLR and C# compiler around 'ref-like' types and Span<>s. Basically a way to let you write 'safe' C# code that interacts with memory that is allocated in different ways (for example with controlled allocation outside of the GC).

Since C# is a multiparadigm language with strong functional as well as OO fundamentals, I suspect it will make it possible for libraries and frameworks to be built which enable allocation free code in C# gameloops. It's not just game engines which have these requirements - the same functionality is also critical for high performance servers, and machine learning applications, so this is a language feature with a lot of demand.

>Same with C++, we were the outliers until console vendors started pushing C++ into devs. See Mike Acton's talks about about how he enjoyed having been forced to move from C into C++.

The first (major) console C++ SDK library is GNM/GNMX for PS4. Are you saying C++ games has been outliers till 201x? I guess this depends on how you define outliers then. Other than the guy casting his game writing on youtube (Code Hero?) I don't know of any significant titles in C past 2000. I have not seen all the games but I shipped a few myself and have friends working on many more and nobody that I know had been writing pure C. Think of all vtbl-> you'd have to write if you are targeting Windows/Xbox just for the pleasure to name your source file .c instead of .cpp!

>What one gets is type safety

Thanks, we've got this in C++ already.

>You know exactly who is responsible for releasing it, there are no double deallocations, releasing invalid addresses, or having to deal with library specific smart pointers (CPtr, QSmartPtr, unique_ptr, my_in-house_ptr, ...).

Never had been a problem for me. The only game I touched that had smart pointers had them because it used NetImmerse and it got cancelled anyways.

>Having a GC doesn't preclude lack of support for cache handling or SIMD.

I don't know what is cache handling, to be honest, but what I meant is that, since GC moves stuff around memory, it's likely to create cache hazards. And since it probably uses a single pool, you cannot change cache policies on per-entity basis.

>As for JIT quality, it is no different from any other compiler, otherwise as I referred, why not discuss C performance using MS-DOS compiler's benchmarks.

Really? You believe JIT will be on-par with a profile assisted, bruteforcing compiler, which can spend a week optimizing a single function?

One problem I have with memory-managed languages for writing high-performance-code is that you need to give up the simplicity of not having to care about memory management. You need to know exactly how the garbage collector in this specific language (and current version of the language) works, and how to build your code around that. The resulting 'mental burden' is the same or even bigger as in C or C++, and the resulting code often looks worse then C++ code which does the same. An extreme example of this is asm.js, much higher performance than typical JS since it only uses numbers, not JS objects (and thus basically removes the need for garbage collection), but so much different from manually written JS that it is basically a different language.

As for smart pointers in C++: they are only useful in a code architecture that essentially emulates C# or Java (all objects as single entities on the heap) using C or C++ in such a "memory-managed style" really doesn't make much sense since it will be slower then a GC. The point about manual memory management is to reduce dynamic allocations as much as possible and have all your data either on the stack or in long-lived, big memory chunks. If you need to allocate and deallocate all the time, or track the ownership and lifetime for every little memory chunk, you're not using C/C++ to its advantage.

PS: C# for tools is great though (not so much because of the language, but because of the standard framework, which is much nicer than the C++ stdlib).

[edit: typos]

Professional journalists write like this, because journalism is intended to be consumed "statelessly"—i.e. with no assumption of previous knowledge.

Writers for "progress announcements" blogs like this one, don't tend to write in this style, because these writers know that the only interest anyone would have in a such a blog is if they already knew what the subject was and then wanted to subscribe for updates.

Which is to say, deep-linking to a progress-announcement blog from another website is basically almost always entirely useless, and the webmasters of such blogs would actually do well to disable it entirely (e.g. with a robots.txt policy + a server-side hotlink-detection redirection rule) and just suggest that people interested in sharing the announcement, should instead write a few lines of "actual journalism" on their own blog about the release, and then share that.

People who like linking directly to primary sources would hate this, but sometimes primary sources are not in the easily-consumed essay or encyclopedia-article styles that much of the modern web has become. Sometimes a primary source is just a commit log, or a diary, where you need to "go back" to get any context. The primary source gets to do what it likes; it's not beholden to the Internet. If someone wants a good summary to share, they're beholden to write one.

The beta version is GPL3; the new version 2.0 apparently is not.