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<T>, classes like
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
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.
This week we continue to look at the C++ that IL2CPP outputs for C# to get a better understanding of what our C# is really doing. Today we’ll look at how abstract methods work, whether casting of sealed classes is faster than non-sealed classes, and what happens when creating a delegate.
The story usually has three parts. First, find the highest CPU cost functions in a profiler. Second, look at the corresponding C++ code that IL2CPP generated from C#. Third, stop using more parts of C#. Today’s article explores some more IL2CPP output and discovers some more areas of C# that are shockingly expensive to use.
Value types like
int, structs, and enums seem simple, but much of what we think we know about them just isn’t true. This article explores how value types actually work in C# and uses that knowledge to improve how they’re implemented in the C++ scripting system.