Unity 2018.1 was released last week and with it comes support for C# 6. Today we’ll take a look at the C++ that IL2CPP generates when we use the new features in C# 6. Warning: one of them is buggy and shouldn’t be used.
Archive for category Unity
Writing multi-threaded code is one of the keys to maximizing performance. Currently, this means creating your own threads and synchronizing them with C# keywords like lock and volatile as well as .NET classes like [ThreadStatic] and Interlocked. Today we’ll take a look at how these are implemented behind the scenes by IL2CPP to get some understanding of what we’re really telling the computer to do when we use them.
Today’s article looks at the IL2CPP and C++ compiler output for a variety of C# language features. Do you want to know what happens when you use them? Read on to find out!
IL2CPP can really slow our code down sometimes, and not just for esoteric features. Calling common math and string functions can be dramatically slower in IL2CPP. Today’s article shows you how you can work around this to speed them back up.
I’ve been writing a lot recently about the C++ and assembly that C# code turns into when it’s run through IL2CPP and a C++ compiler. Today’s article shows you the steps so that you can see what your own game’s C# code turns into.
C# has some powerful features like fixed-size buffers, pointers, and unmanaged local variable arrays courtesy of stackalloc. These are deemed “unsafe” since they all deal with unmanaged memory. We should know what we’re ultimately instructing the CPU to execute when we use these features, so today we’ll take a look at the C++ output from IL2CPP and the assembly output from the C++ compiler to find out just that.
Unity’s GC is a continual thorn in our sides. We’re constantly working around it by pooling objects, limiting use of language features, and avoiding APIs. We even call GC.Collect on load screens in the hopes that the GC won’t run during gameplay. Today’s article goes one step further and shows how to disable the GC completely so there’s zero chance it’ll run. We’ll also see how to turn it back on when we’re ready for it again.
C# allows for overloading not just function names, but also type names. This is used throughout the .NET and Unity APIs for interfaces like IEnumerable and IEnumerable<T>, classes like UnityEvent<T0> and UnityEvent<T0, T1>, and delegates like Action<T1, T2> and Action<T1, T2, T3>. C++, however, does not support type overloading. Today’s article explores how to deal with this and, once we’ve solved the issue, what extra C# features we’ll have access to in C++.
Since their introduction in part 7, support for C++ MonoBehaviour messages has always been a special case. The reason for this was that we didn’t have good enough support for what I’m calling “factory functions.” These are functions like GameObject.AddComponent<T> that instantiate a generic type. This week we’ll go over why that support was lacking, what was done to fix it, and how the new system works.
There are many permutations of loops we can write, but what do they compile to? We should know the consequences of using an array versus a List<T>, for versus foreach, caching Length, and other factors. So today’s article dives into the C++ code that IL2CPP outputs when we write these various types of loops to examine the differences. We’ll even go further and look at the ARM assembly that the C++ compiles to and really find out how much overhead our choices are costing us.