[Official] The collected il2cpp forum topic.

News & General Discussion
1

In following of our blogpost about the future of scripting and il2cpp, we wanted to centralize discussion about it here, next to the comments. We’re very excited to be talking about this. We’ll all be watching this thread and answering your questions; the blogpost is explanatory about the topic, so we’ll pick up what ever comes up in questions here !

2 Likes
2

Do I read that right, that the first platform will be WebGL, the second iOS? Do I miss “PC, Mac Standalone” or is that intended for a future release?

1 Like
3

Thanks for a great blog post there. IL2CPP sounds very exciting but, I’m with Carpe Denius here, I’m a little worried that ‘PC, Mac, Linux’ standalone doesn’t seem to get a huge amount of attention.

1 Like
4

I’d assume that’s because IOS is already AOT.

5

The plan is definitely to move more platforms over to il2cpp. AOT platforms like iOS are an ideal first goal, though, as

  1. they are AOT already, so you can expect a more seamless transition, and

  2. because they are AOT, they cannot use mono according to the LGPL, which is currently preventing us from updating mono. So once we have AOT platforms on IL2CPP, there is nothing stopping us from using the latest mono in the editor and other platforms.

7 Likes
6

Seriously?!? I mean… seriously?!?

7

Can you specify that question?

1 Like
8

Do consoles already run on a different base or are they Mono? Probs will be a big wait if all the consoles need to be ported before the normal platforms.

9

I don’t believe the consoles have restrictions that prevent LGPL code from being used, so I imagine they’re using Mono like everything else.

10
  • VM machines for every platform which means binding people on those VM for several months
  • Reimplementing the entire CLI background (not the entire toolchain… at least, they didn’t do that…)
  • Going from JIT to AOT (AOT is platform dependent, so you ideally need a compiler and SDK for that platform)
  • WebGL as first platform (WHO is going to use that if you have to pay this… or are you going to drop the webplayer?)
  • Going from C#/UnityScript/Boo(?) to IL to CPP to machine code adds an additional layer of possible “shit that can go wrong”
  • Still in research…
  • … and thus could be not viable on specific platforms… which means that the difference between the platforms can and will be increased as we cannot be sure anymore that the code on one platform runs smooth on another one.

Knowing Unity and their history of long turn around times, we can expect the scripting features go downhill for a while before climbing back up the hill again… has been like that with any other feature Unity has provided up to now… will not change in the future (unless you prove me wrong)…

11

Internally, most development is done using Standalone players as they are easy to build, debug, and test on. So, they are receiving more direct attention than most.

However, the existing Standalone player is not currently AOT and exposes the most .Net functionality of any supported player. That means

  1. An IL2CPP of the Standalone player will have less functionality than current Standalone as it restricts features to AOT compatible ones
  2. The chances of a project working ‘out of the box’ in Standalone is less as existing projects will be using some things that don’t work in AOT mode
  3. Mono is most robust and stable on x86/amd64, so IL2CPP is not as in demand on those platforms

tl;dr; Standalone players work internally with IL2CPP as well as any other platform, but they are not the focus for IL2CPP in the near term. I’d guess that we may ship them as an option alongside mono Standalones for you to test/debug with.

12

il2cpp sounds very exciting!

I’m using Unity views as a part in a bigger, native iOS/Android app quite often. The communication is from CPP to C# is via MonoBindings.

In a future with IL2CPP, will it be possible to hook up custom C++ code? In other words, will we have access to the unity generated code BEFORE final compilation? Or is the only way to do so by loading runtime libraries?

thanks!

13

Thanks a lot for sharing that information! This is really appreciated!

14

I forgot about that. So stuff like reflection won’t work anymore with IL2CPP?

15

@RalpH so standalone are less stable in IL2CPP?

16

We already have this with Mono, in a much harder to maintain situation

Yes, we are not trying to reinvent the wheel.

Yes, the choice was to leverage all the work being done by the C++ compiler vendors rather than writing and maintaining all the code generation, optimization, etc ourselves for each architecture in mono.

I won’t go into pricing, but dropping the web player is not our choice as mentioned many other places. At least 2 top browsers are going to be disabling plugins which is out of our control.

Almost all this applies to Mono, or any JIT/compiler

I’d say things have been going downhill and this is our best attempt at resolving that.

17

I’m not completely surprised by this announcement, having been at the GDC WebGL talk. They hinted at other possible uses for the technology, but it’s definitely a bold direction to move in. While I actually do find this to be very cool (I love C#), it sort of begs the question… why not just allow side-stepping to c++? I mean, it’s not my favorite language, but it would not be the end of the world for me, and it would enable those who want the performance to get it.

18

Reflection will work. Stuff like System.Reflection.Emit will not. No dynamic code generation at runtime.

19

Most of reflection will work, just not dynamic code generation.

20

You can already write C++ when you need it via plugins. You can’t script directly in C++, but you can easily move performance intensive logic there if you need it.

The problem with exposing C++ as a ‘scripting’ language is that you still need to deal with all the rules of the .Net ecosystem (garbage collection for example). We have found internally that writing C++ which plays by the rules is extremely hard.