Categories & Tags
Archive

The future of scripting in Unity

May 20, 2014 in Technology by

Recently we talked about Unity and WebGL. In that post we briefly spoke about how scripting works in WebGL, using new technology called “IL2CPP”. However, IL2CPP represents a lot more than just a scripting solution for WebGL; it’s our own high performance .NET Runtime, to be rolled out on more platforms.

But before we delve into the future, let’s talk about the present.

Scripting in Unity today

We leverage Mono (and WinRT on Windows Store Apps and Windows Phone) to bring the ease of use of C#, access to 3rd party libraries, and near native performance to Unity. However, there are some challenges:

  • C# runtime performance still lags behind C/C++
  • Latest and greatest .NET language and runtime features are not supported in Unity’s current version of Mono.
  • With around 23 platforms and architecture permutations, a large amount of effort is required for porting, maintaining, and offering feature and quality parity.
  • Garbage collection can cause pauses while running

These issues have remained in the front of our minds over the past few years as we sought to address them. Concurrently, investigations into supporting scripting for WebGL were occurring. As each progressed forward, these two paths converged into a single approach.

With the problem scope clear, experimentation on different ways to solve this were tried. Some of them were promising; others were not. But ultimately we found an innovative solution and it proved to be the right way forward.

That way forward is IL2CPP.

IL2CPP: the quick and dirty intro

IL2CPP consists of two pieces: an Ahead of Time (AOT) compiler and a Virtual Machine (VM).

These two parts represent our own implementation of the Common Language Infrastructure, similar to .NET or Mono. It is compatible with the current scripting implementation in Unity.

Fundamentally, it differs from the current implementation in that the IL2CPP compiler converts assemblies into C++ source code. It then leverages the standard platform C++ compilers to produce native binaries.

At runtime this code is executed with additional services (like a GC, metadata, platform specific resources) that are provided by the IL2CPP VM.

The benefits of IL2CPP.

Let’s talk about each one of the previously mentioned issues and how IL2CPP addresses each of them.

Performance

IL2CPP seeks to provide the ease of use and productivity of C# with the performance of C++.

It allows the current, productive scripting workflow to remain the same while giving an immediate performance boost. We’ve seen 2x-3x performance improvements in some of our script-heavy benchmarks. This performance boost is due to a few reasons.

  • C++ compilers and linkers provide a vast array of advanced optimisations previously unavailable.
  • Static analysis is performed on your code for optimisation of both size and speed.
  • Unity-focused optimisations to the scripting runtime.

While IL2CPP is definitely still a work in progress, these early performance gains are indicative of great things to come.

.NET Upgrade

A very frequent request we get is to provide an upgraded runtime. While .NET has advanced over the past years, Unity currently supports .NET 2.0/3.5 era functionality for both the C# compiler and the class libraries. Many users have requested access to newer features, both for their code as well as 3rd party libraries.

To complement IL2CPP, as it matures, we will also be upgrading to recent versions of the Mono C# compiler, base class libraries, and runtime for use in the editor (The editor will not switch to IL2CPP, for fast iteration during development). These two things combined will bring a modern version of .NET to Unity.

It’s also important to note that we are collaborating with Microsoft to bring current and future .NET functionality to Unity, ensuring compatibility and quality.

Portability and Maintenance

While this area may sound like an internal issue for Unity to deal with, it also affects you. The Mono virtual machine has extensive amounts of platform and architecture specific code. When we bring Unity to a new platform, a large amount of our effort goes into porting and maintaining the Mono VM for that platform. Features (and bugs) may exist on some platforms but not others. This affects the value which Unity strives to provide to you; easy deployment of the same content to different platforms.

IL2CPP addresses these issues in a number of ways:

  • All code generation is done to C++ rather than architecture specific machine code. The cost of porting and maintenance of architecture specific code generation is now more amortised.
  • Feature development and bug fixing proceed much faster. For us, days of mucking in architecture specific files are replaced by minutes of changing C++. Features and bug fixes are immediately available for all platforms. In it’s current state, IL2CPP support is being ported to new platforms in short amount of time.

Additionally, platform or architecture specific compilers can be expected to optimise much better than a singular code generator. This allows us to reuse all the effort that has gone into the C++ compilers, rather than reinventing it ourselves.

Garbage Collection

IL2CPP is not tied to any one specific garbage collector, instead interacting with a pluggable API. In its current iteration IL2CPP uses an upgraded version of libgc, even as we look at multiple options. Aside from just the GC itself, we are investigating reducing GC pressure by analysis done in the IL2CPP compiler.

While we don’t have a lot more to share at the moment, research is ongoing. We know this is important to many of you, we’ll continue working on it and keep you informed in future blog posts. Unrelated to IL2CPP, but worth mentioning in the context of garbage collection, Unity 5 will see more and more allocation free APIs.

What IL2CPP is not

IL2CPP is not recreating the whole .NET or Mono toolchain. We will continue to use the Mono C# compiler (and perhaps later, Roslyn). We will continue to use the Mono class libraries. All currently supported features and 3rd party libraries which work with Mono AOT should continue to work with IL2CPP. We are only seeking to provide a replacement for the Mono VM and AOT compiler, and will keep on leveraging the wonderful Mono Project.

When can I try IL2CPP?

By now we hope you are just as excited as we are to use IL2CPP and wondering when you can get your hands on it! An early version of IL2CPP will be available as part of WebGL publishing in Unity 5.

Beyond WebGL, we are continuing development of IL2CPP for other platforms. In fact, we already have working implementations on a number of our supported platforms. We expect to be rolling out at least one additional platform later this year. Our current plan is to have iOS be the next platform shipping with IL2CPP support.

The planned upgrades of our Mono toolchain will follow after IL2CPP is available on more platforms and has matured.

One platform that will never be supported by IL2CPP is the WebPlayer; this is due to security implications. And as noted earlier, the editor will remain to be using Mono.

Additionally, you can see the IL2CPP runtime in action today. As mentioned, the two WebGL demos we posted are IL2CPP-powered.

What’s next?

We are still hard at work on IL2CPP: implementing new features, optimising code generation, fixing bugs, and supporting more platforms. We’ll keep posting more in-depth blogs as we make progress and talk about it with you on the forums.

The Scripting Team.

Share this post

Comments (79)

Comments are closed.

20 May 2014, 2:25 pm

Thanks for sharing with the community!
I know many people are concerned with Unity’s performance and many people would like to see Unity using native .NET on Windows 8 platform. Good to know that you are working towards these goals!

20 May 2014, 2:27 pm

If the code is compiled AOT to native (C++) why would you need a VM for ?

Jonas Echterhoff
20 May 2014, 2:35 pm

@LIOR: The term “VM” may be a bit misleading here. There is no VM actually running some sort of meta code, it is all native code, but there is set of runtime functions implementing functionality needed by managed code, like some system services and GC, which we call VM in this case.

20 May 2014, 2:41 pm

Would this mean we’ll be able to use our own C++ code with unity?
Something similar to what the NDK provided to c++ developers in Android?

Anthony
20 May 2014, 2:44 pm

I noticed that my game that i was working on ran fine on the win 8 desktop and tablet. The game i was working on was an endless runner and I had tons of things spawning and destroying constantly. The game ran very smooth until i ported it to win phone 8.1 and every time a gameobject was destroyed, the game lagged for a split second. :(

20 May 2014, 2:44 pm

@David, that is not the goal of il2cpp, but over a very long term could be an artefact. But this is not “introducing; writing your scripts in C++”.

SleepyDaddySoftware
20 May 2014, 2:45 pm

Please please please please open source IL2CPP, with the apache 2 license. There are a TON of potential applications of this technology beyond games and Unity would benefit from community involvement in the project.

David
20 May 2014, 2:55 pm

F*** YEAH!

Trap
20 May 2014, 2:58 pm

I always wondered why this was never the first option. You could even allow mixing c# and c++ code. Way to go.

20 May 2014, 2:59 pm

@SLEEPYDADDYSOFTWARE we have been discussing how to deal with il2cpp in that context and frankly, right now we are not committed to open sourcing it. That being said, I think there are benefits to Open Sourcing it, but equally there are downsides/implications for us to do that and it would have to be a pretty significant return (that we haven’t been able to identify) for us to open source it.

TLDR; no plans to that right now

20 May 2014, 3:16 pm

That’s really great news, as Unity will finally be able to fully control the substantial part of it’s technology and not depend on Xamarin.

20 May 2014, 3:34 pm

native code is the past, c# + gpu computing language like ION# is the future

https://www.youtube.com/watch?v=2TwL7kY5fsk

Francisco Requena
20 May 2014, 3:35 pm

About Roslyn, there’re real plans on moving there or it’s not yet considered?

Also, “we will also be upgrading to recent versions of the Mono C# compiler, base class libraries, and runtime for use in the editor”. Does this means those features will not be available on players? Can you tell more about that?

Thanks!

20 May 2014, 3:39 pm

This sounds all very great! Will this approach have any limitations compared to traditional Mono? (i.e. in the WebGL demo, the page mentioned that it will not support “Any .NET features requiring dynamic code generation” – I assumed this was a limitation of the compile-to-C++ process rather than the browser itself)

Jonathan Chambers
20 May 2014, 3:39 pm

@FRANCISCO we gave Roslyn a try and found it slower than the Mono C# compiler currently.

“we will also be upgrading to recent versions of the Mono C# compiler, base class libraries, and runtime for use in the editor”

This means updated compiler and base class libraries are planned to be available everywhere; output will run on Mono in Editor and probably Standalone players, IL2CPP most likely for other platforms.

Ray
20 May 2014, 3:41 pm

@Dallon The dynamic code generation issue is inherent to AOT, same as iOS today.

Jonathan Chambers
20 May 2014, 3:42 pm

@DALLON IL2CPP is an AOT technology similar to Mono AOT. Thus it will have the same restrictions as Mono AOT. See the “No Dynamic Code Generation” section in the Xamarin documentation http://docs.xamarin.com/guides/ios/advanced_topics/limitations/

Kr0e
20 May 2014, 3:46 pm

@DMITRIY:

Wrong, they still heavily rely on the mono-tool-chain. And this is not a bad thing, Xamarin is a great company which helped C# to become more what it is today. I can’t see any downsides of this.

20 May 2014, 3:56 pm

@KR0E @DMITRIY absolutely, by no means does it mean we’ll discard all the hard work put into the Mono Project; we are implementing another way of targeting a platform and running that code, but it is just that and that alone we are talking about.

Sebastiano
20 May 2014, 4:33 pm

Will we see this for Windows standalone?

20 May 2014, 4:35 pm

Does that means that sooner or later there will be no way to do dynamic code generation and even no way to load .NET dll assemblies in run-time? These are quite major things… Will there be an options to select a runtime the build will use?

Andrew Gratta
20 May 2014, 4:36 pm

Thanks you!

20 May 2014, 5:12 pm

This sounds great, but will Unity publishing to WebGL still work with good old fashioned UnityScript? I use Unity3D in the classroom where we’re not as concerned with maximum performance as we are with accessibility. I hope my UnityScripting students will also be able to publish to WebGl. :-)

Jonathan Chambers
20 May 2014, 5:22 pm

@MARTY IL2CPP operates at the IL level. Theoretically, that means any .Net compatible language will work. In practice, it requires that the language not generate code at runtime. For example, I believe UnityScript requires the ‘#pragma strict’ statement to avoid runtime code generation.

20 May 2014, 5:22 pm

@KR0E @RALPH HAUWERT

By no means I assume that Unity should get rid of Mono.

But scripting is really a fundamental part of Unity, and it’s development is bound by not being able to use fresh version of Mono.

As far as I undestand, Mono open license obliges you to make the Mono part of the built game be interchangeable and updatable to newer versions of Mono. And it’s not possible to get a special license for this case.

So I’m very happy, that there will be no more showstopper like this.

Jonathan Chambers
20 May 2014, 5:23 pm

SEBASTIANO & ZIMM there are more details for this topic on the forum. Basically, the thought is IL2CPP will come to Standalone players someday; but it is not a priority and it will not replace Mono but co-exist as a build option.

20 May 2014, 5:40 pm

Sounds like IL2CPP would be nice for AAA developers working on cutting edge games. I don’t think this applies to the majority of Unity’s user base though.

It is still unclear to me how IL2CPP would mix and integrate with existing C# / Javascript, particularly assets from the store, and our existing scripts. Hopefully the addition of another development language will not amplify the already annoying fragmentation between Boo (does anyone even use that?), C#, and Javascript.

When I say fragmentation between these languages, I’m just talking about how it’s really annoying using Javascript and C# side by side – have to always be thinking about compilation order, making javascript scripts available in c# intellisense, etc, etc. Even though the languages work side by side, in a production environment I don’t think they are both used together extensively.

Jonathan Chambers
20 May 2014, 5:43 pm

@PHIL IL2CPP works at a level after what you describe. It converts the IL into C++; IL which is contained in the assemblies built from all your scripts, asset store scripts, and prebuilt assemblies either from Unity, the Mono class libraries, or 3rd parties.

pedro
20 May 2014, 5:56 pm

Since Microsoft open sourced the C# compiler and language I imagined it would be easy to just make everything work natively in any OS.

20 May 2014, 6:09 pm

@JONATHAN thanks for the clarification – my apologies; I’m at work and I didn’t completely read into how IL2CPP works (I guess the acronym should have given that away).

So in a nutshell, this means all the unity scripts gets compiled into intermediate language, and that gets compiled into C++ for a performance boost?

I guess i’m just looking for a TL;DR explanation of what kind of changes this means for unity3d developers. The workflow remains the same, and the compiliation to native C++ is an after-the-fact performance optimization?

Chris Hill
20 May 2014, 6:15 pm

Cool stuff guys! I’m excited to see this happen. So many questions tho!

I’m curious how this new approach changes the concepts of the heap and garbage collection. Will we still have a concept of a mono heap? Does this allow for things like implementing heap compaction and a generational collector?

I was also curious if this improves the overall binary size compared to that of the mono AOT compile. Does it compile faster and does the Dsym generation actually do something useful now? :D

Richard Fine
20 May 2014, 6:38 pm

@PHIL WINKEL: Yes, that’s about the size of it. It’s also going to result in an updated Mono for us at some point, which may mean support for newer language features and stuff.

20 May 2014, 7:03 pm

That’s good news – thanks for the reply Richard.

I love the depth of technical detail included the article – but I feel like the article could use a TL;DR right at the top :)

Abscissa
20 May 2014, 7:42 pm

Wow, I’m actually really excited about this.

I do have a few questions though:

- Any plans to offer an ARC solution as a (sort of)”GC”? Even if it’s backed by a regular GC for cycles, that would still be really nice to have.

- *Please* tell me this makes it possible to *directly* link with native C-linkage code, bypassing any marshalling or C# “stubs” that only serve to bridge the scripting world with external C-linkage native code.

- Related to the previous point, how “transparent vs black-box” will this toolchain be? For example, back when I used Marmalade, their mandatory C++ buildscripts were a proprietary buildsystem written in pre-compiled Python with no source available. That made it very difficult to insert additional steps into the build process. With your system, will I be able to modify the cmd line used to invoke the C++ compilers, and will I be able to add custom pre-/post- steps before/after the C++ compiler is invoked. I don’t mind having to modify makefiles or buildscripts to do this as I’m well-versed in such things. I’m just hoping it will at least be possible.

20 May 2014, 8:16 pm

Exciting news indeed.

Smooth P
20 May 2014, 8:51 pm

So, the latest and greatest version of the Mono AOT will be used to compile IL (including Mono’s current implementations of .NET libraries), then IL2CPP will translate to C++, which is then compiled to platform specific native code?

So there will be no JIT on any platform?

How will compiler optimizations such as inlining be applied?

And how will this impact the use of generics, which are currently absolutely brutal on AOT platforms?

20 May 2014, 8:58 pm

(Edit: I meant to say the Mono C# compiler would be used to go from source -> IL, not the AOT.)

Jonathan Chambers
20 May 2014, 9:16 pm

CHRIS this changes nothing for the concepts of a GC or managed heap. All the same rules apply as to how memory to allocated and tracked. As mentioned the post, the GC is accessed via an API. While we have an implementation of Boehm supported using this API, we are actively pursuing other options for garbage collection.

Jonathan Chambers
20 May 2014, 9:20 pm

ABSCISSA no plan for ARC. But again, a ‘real’ GC is being used just by an other CLI implementation (.Net or Mono).

Mono and IL2CPP allow for ‘Internal Calls’, calls directly from managed into native. These perform no marshalling, but have some restrictions. These are what Unity uses to bind native and managed code. We may be able to ease the process to use these calls within user code.

For WebGL we drive the toolchain directly. For something like iOS, I would expect it to be similar to the workflow today where a project file is generated that can be built with XCode.

Jonathan Chambers
20 May 2014, 9:22 pm

SMOOTH P latest and greatest version of Mono C# compiler will be used at some point.

The Mono JIT will remain available within the Editor and Standalone.

Not sure about your inlining question.

Generics will be restricted similar to AOT platforms today, although IL2CPP already seems to handle more cases than our current mono version.

Stefano Cecere
20 May 2014, 9:50 pm

even if i like C#, it’s a bit a pain to code for it on OSX (only with Visual Studio + Resharper on Virtual machine we could live)

how it would be nice if Unity move to pure C++ (we have perfect IDEs for C++), or even better pure JS (not UnityScript) compiling into asm.js

Sebastian
20 May 2014, 11:22 pm

Great stuff, this sounds really good!!

koblavi
21 May 2014, 12:16 am

This is wonderful news on many levels! Unity 5.x is looking to be the most promising version of Unity yet!

And I don’t know about the rest of the community, but I for one appreciate how you’ve engaged us on some of the low level implementation details of Unity these last few days. We’d like to see more posts like this!

Power to Team Unity! Don’t stop till Activision starts making COD with Unity :-D

The_Grand_User
21 May 2014, 12:54 am

This seems very similar to Microsoft’s .Net Native project/compiler, have you looked into that with your collaborations with them?

And I certainly do hope you eventually incorporate Roslyn, and get some of that async niceness in :)

21 May 2014, 3:53 am

Glad to see flash exporter team now works on the IL2CPP and WebGL stuff, this is so amazing to see what you guys are preparing for us. Thank you for sharing current progress, looking forward to any new posts about IL2CPP!

Unity3dx
21 May 2014, 5:26 am

Why not supporting C++? It is the most solid compiler ever, code created 20 years ago still can be re-used. Depending on C# is suicidal, as we all know that Microsoft makes money by killing its own concepts to and creating new ones, forcing everyone to follow and re-buy all their products. C# will not be an exception to the rule. See Visual Basic=dead, ASP=dead, MFC = dead etc… CPP is independent, free, cross platform and f..damn fast. Guess why UDK is using it.

Tobsen
21 May 2014, 7:54 am

Not sure if @UNITY3DX is trolling… Productivity and ease of use => effectiveness and efficiency while developing. IMO that’s as important as runtime performane

21 May 2014, 8:07 am

Sound fantastic! Thanks for the insight!
Just one question: Editor and Build using different systems sounds scary to me – doesn’t this mean that there’s a good chance that some bugs will only show up in the build (and thus be more or less impossible to find and fix for the average user)?

koblavi
21 May 2014, 8:45 am

I Agree adding some sort of managed C++ support is worth looking into for the future (i.e. Skipping the initial c#->IL compilation step.) Of course, at this point I really do not see the added benefit except making the C++ fanboys happy. Perhaps afterwards, we’d see community of people coming onto the blogs asking for platform specific “pure” assembly support. :-D

@UNITY3DX
Microsoft does not own the C# language; it’s an open standard. So even if MS itself died today, C# will still be maintained. C# is an excellent language! It’s not right to hate it just because it was invented at Microsoft!

Richard Fine
21 May 2014, 9:49 am

@COL000R: But it’s already the case that the Editor uses a substantially different runtime to, say, iOS. It’s already possible for there to be bugs in one platform’s Mono implementation (or engine code) that don’t show up in the Editor.

horeaper
21 May 2014, 10:01 am

This does sounds a lot like Microsoft’s .NET Native. An in-depth comparison would be nice!

21 May 2014, 10:18 am

@COL000R That is really no different that what the situation is today; running in editor on jit’ted 86/x64 vs running on AOT mono on iphone is as likely to have differences, so no need to be scared there.

Of course that is a shortcut in the fact that that issue might exist even in the new situation; however, our work to get this very well tested against our own test suites, as well as extending that to the test suites that Microsoft shared with us we are aiming to minimise those risks.

add
21 May 2014, 11:19 am

Why not just add c++? There’ people who have mastered c++.

guter
21 May 2014, 11:31 am

Add c++ is better than making c# to c++.

= boo, c#, java and c++.

DaveM
21 May 2014, 12:25 pm

I actually think this is good news because of the boosting alone. but i’m guessing there will be more features revealed as we get closer to the launch of Unity 5???

21 May 2014, 12:32 pm

@SecondLevelSupport: You guys have heard of LLVM, right?
maybe you should investigate into this one first, before writing your own IL2CPP converter. :)

http://en.wikipedia.org/wiki/LLVM

21 May 2014, 12:36 pm

@JAN WOSNITZA, we actually have quite some experience with LLVM, albeit more with backends then frontends, and we actually did investigate options there too; believe me, we have explored, experimented and worked on a number of avenues and with that knowledge decided IL2CPP is the best option.

SleepyDaddySoftware™
21 May 2014, 8:43 pm

@RalphHauwert That’s disappointing to hear. Could you elaborate on what your perceived risks/costs would be w.r.t. open sourcing IL2CPP? I know that open sourcing any part of a commercial product has some risks and challenges involved, but I think in this case you are underestimating the benefits and overestimating the costs.

Developers would still need to license Unity to use IL2CPP with it, so I don’t think it directly threatens Unity revenue. Sure, alternative game development frameworks might deploy using IL2CPP, namely MonoGame and Cocos2dXNA, but in terms of commercial quality tools and support, Unity is still the king. Your pricing tiers are excellent value, and the quality of your tools are great, so there isn’t much motivation for a Unity developer to switch. Plus, you seem to be doing well even on platforms where the full .Net runtime is available for free for commercial development.

On the benefits side: as I said before, IL2CPP has applications beyond Unity development, from mobile app development, to embedded/robotics, scientific computing, and so on. You could build a community and ecosystem around IL2CPP that could result in community contributions for platform ports, platform-specific optimizations, support for new platforms and devices – not to mention bug fixes, alternate garbage collectors, and so on.

Speaking more broadly, the .net ecosystem NEEDS a portable, permissively licensed runtime, AOT or otherwise. In terms of developer mindshare, .net is hemorrhaging developers towards native C++ and JavaScript/Asm.js – both of which either are broadly available runtimes or completely open implementations. I know you’re a game development tools company, so this isn’t really your problem to solve – but, it’s always been my belief that a healthy, vibrant .Net community would benefit everyone involved. Also, you’ve experienced yourself the licensing issues involved with the existing portable .net runtime, Mono. The issues you’re having are the issues that everyone is having. Xamarin can’t license Mono under the Apache 2 license because that’s their entire revenue stream. But you can release IL2CPP as Apache 2, because YOUR revenue stream comes from Unity, not the runtime. In fact, you continue to be successful even on platforms where either a .Net runtime is free to use commercially (windows), or where it’s possible to use Mono under the LGPL license for commercial development (Linux steam games, Mac Desktop apps outside of the App Store).

I implore you to reconsider this decision – if not now, then perhaps later once IL2CPP matures internally. Whatever you decide though, I think it’s a great technology and I’m looking forward to seeing more of it.

21 May 2014, 9:23 pm

Why not add direct C++ support? UE4 have done a nice job supporting C++. Automatic GC, automatic memory management with the option of managing your memory if you want to get dirty, macros, Reflection, Generics, C++11 support, you name it. It’s a pleasant C++ game programming environment.
I would move all my projects to Unity if there’s C++ support. Too bad we would never see such thing.

22 May 2014, 4:50 pm

Sounds awesome. Hope it doesn’t take too long for IL2CPP to hit Windows/Mac/Linux builds.

22 May 2014, 7:09 pm

@SLEEPYDADDYSOFTWARE I absolutely see your point as a benefit for the .NET community at large. We’ll keep on evaluating our own position on this, but right now this is the call we made.

22 May 2014, 7:10 pm

@Codemonkey again C++ support for unity is not the scope of IL2CPP, but it does open up some doors for the future.

23 May 2014, 3:39 am

@Ralph, I understand is not the scope of IL2CPP.
Hoping to see C++ first class citizen in Unity6! :D

KElvin
23 May 2014, 6:29 am

I am still a bit confused, can someone clarify the IL2CPP?
From what I am reading, it seems to be a new runtime for Unity3D working alongside Mono and etc…

Fritz
24 May 2014, 9:29 am

I’m not trolling, but it’s just sad to see so much effort being put into what are basically workarounds for an insufficient platform. I agree with the above posters, why not just create a nice and easy to use C++ API and be done with it?
Same goes for the whole Microsoft Native .NET initiative, b.t.w. – why didn’t they just create a nice C++ GUI Toolkit and class library? Instead they keep throwing technologies at us that later turn out to not stand the test of time.

Aqo
24 May 2014, 3:22 pm

Why time with a proprietary .Net, Microsoft sucks hard!

rocky
25 May 2014, 6:51 am

mono editor in comparison with vs 2010 is weak !(very weak)

Samhayne
25 May 2014, 9:08 pm

Why no direct C++ scripting at this point of time?
It’s pretty obvious that the main mission for the team is getting WebGL exports running at decent speed.
And it seems like the C# => C++ => LLVM => emscripten chain works better or is more maintainable than going the direct C# => LLVM => emscripten path

Increased speed for standalone builds looks like just a welcome side-effect that strengthened the decision to go this way.

It’s very unfortunate though that the webplayer (again) won’t benefit from it.
It’s really a path of letdowns working on webplayer applications… and it’ll surely still take
1 or 2 years until WebGL will become solid (while probably still slower than the webplayer).
I wish there’d be a sandbox mechanism…. :-/

26 May 2014, 10:58 am

C++ for scripting ?
What ???? C++ is not made for scripting. Unreal has made a decision orientated for AAA prod.
Unity don’t have to follow it.
You should ask yourself: Do you want your game to play at 32Fps instead of 31Fps but took you 10 months instead of 6 to make ?
Another question:
Do you want your game made in 10 months to have 3 bosses, 40 levels, 10 enemies and run at 31FPS, or a game with 3 bosses, 25levels, and 6 ennemies but play at 32fps ?
What is best for the player ?
Of course if you’r AAA you can stupidly waste one or two programmer full time to get this 1fps, but if your an indie, for me that’s a bad choice (or you believe that scaling a production pipeline of a AAA production to an indie don’t need any adaptation..).
(C++ for engine, not for scripting!!!)

Stop lobbying for C++, that’s not a good idea!

Khaled
2 Jun 2014, 1:04 am

Have you consider D programming language for your engine? If not, check the following link: http://dlang.org/ I think this is a great opportunity that would benefit Unity to achieve the goals mentioned above.

Wally_B_Feed
2 Jun 2014, 10:32 pm

@ALEX:

I bet the fps gain would be far higher than just 3%. ;)
Don’t panic… even IF there was C++ support one day, Unity would never stop
supporting C#/UnityScript.

I would still love it… there are dozens of algorithmic areas in our project which
I’d like to speed up by replacing C# with C++.
But… for the webplayer it will probably stay a dream forever.

4 Jun 2014, 12:53 am

Faster games and easier compile pipeline is always nice.
But what about interactive scripting?

4 Jun 2014, 2:17 am

I am also curious about run-time assembly loading support. Kerbal Space Program uses this method for mods, and we are planning to use it to. It’s quite useful for hotloading specific code! How will IL2CPP interact with this? Can we still call into .NET assemblies before, or maybe IL2CPP will compile it dynamically?? :)

4 Jun 2014, 7:14 am

@Steve IL2CPP, being an AOT (ahead-of-time) compiler, will not be able to “compile dynamically. Equally hotloading of code isn’t supported.

@Laurent I’m not sure what that means, “interactive scripting”.

6 Jun 2014, 9:51 am

@Ralph interactive scripting: you run the game, change the script and, without any delay, the game logic/ mesh creationg, whatever changes without losing initialized variables, in real time, like you get in Lua or, from what I see in the videos, Apple Swift.

To expand on this, the bottleneck that remains in Unity, the only thing that doesn’t update on the fly is scripting and so it would seem logical to solve that as a “future of scripting”.

Yury Zholobov
12 Jun 2014, 1:13 am

Have you seriously considered LLVM option? What about Microsoft’s “.NET Native”? If you did not consider them, then why? If you did, then can you share your reasoning not to reuse them?

Luke
13 Jun 2014, 2:39 am

Thank you so much for this in depth/behind the scenes info. I really appreciate the openness.

16 Jun 2014, 11:00 pm

Awe damn it. Garbage Collection is a dead end guys! Stop trying to do memory allocations with GC, it’s a path to confusion and frame hiccups. That’s deadly for VR applications. We need a memory manager model similar to Apple’s ARC, where objects are killed in realtime, and testable in a debug environment. It also needs to be usable, and C++ smart pointers are tricky to use correctly, thus why the GC approach. Solution was an will always be weak linking between objects, and a language level memory retain counter.

7 Jul 2014, 10:55 pm

Its really informative post .

Leave a Reply

Comments are closed.