A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'General Discussion' started by RalphH, May 20, 2014.
* apple app store not asset store...and thanks!
@JoshPeterson Hi there, Congrats on this awesome new tech! Very excited about it
Our assets "UFPS : Ultimate FPS" and more specifically "Mobile Add-on for UFPS" will build fine to iOS devices using Mono, but will hang using IL2CPP. I have tracked down these issues to our event system, and have submitted my findings in case 673217.
Any assistance with this would be much appreciated since we have customers waiting to submit to App Store.
IL2CPP broke Photon Unity Networking plug-in.
I've opened issue 677305 in Fogbugz, marked it as public but it's not showing in issues for us to vote up...
I'm kinda desperate here, decided to go with Photon because it's such an excellent networking solution and now IL2CPP broke it right as I've finished development, and of course Apple won't take new submissions that aren't 64-bit.
It appears to be a bug in your C# Sockets implementation of IL2CPP.
Here's the topic on Photon's forum:
I'd like to confirm my understanding of the state of affairs with IL2CPP:
IL2CPP for iOS was released last year with Unity 4.6.1p5, back-ported from 5.0 due to the Apple-mandated need for 64-bit which IL2CPP provides.
In addition to IL2CPP for iOS, there is a preview-version of IL2CPP for WebGL in Unity 5.0.
IL2CPP has NOT been implemented for any other platform in 5.0, but will be rolled out in 5.x releases.
Yes, but I'd add that the "backporting" was really only making 4.6 capable of building using IL2CPP. The updates for IL2CPP are actually rolling out to the 4.6.x branch a little more quickly than 5.x. This is strictly due to release cycle since it is just one IL2CPP product that is being used for both versions.
il2cpp is hanging for me when building for ios on Unity 5...
any idea when the next patch release for il2cpp is?
And looks like there is one out now.... testing....
Still hangs... nothing in player.log or editor.log :-(
Will try to isolate what is causing it....
Anyone else experience extremely long build times using IL2CPP? Takes roughly 15 minutes to build from about 1 - 2 minutes.
This is known. IL2CPP actually always will take long as the code has to be first compiled to IL and then converted to native CPP. The Unity team is however continually working on bringing down build times. If this is for a WebGL build, try disabling compression (maybe this is done automatically for dev builds, I can't recall) when testing as it will reduce your build time.
Can users change the C++ compiler flags? Then they could try a faster compile mode (e.g. less optimizations).
No idea as it's Unity's proprietary compiler. That would be a good question for them though.
I'd really like to see IL2CPP for standalone as soon as possible, even as an alpha or beta option.
I think IL2CPP support for windows standalone is more important than people think. We need that extra security asap. Decompiling C# is too easy.
I really don't think you do... reason outlined below
It is important, for security and performance but we don't want it yet in its current state. Unity are continuing to improve the product both for feature support and performance. There is another catch though... IL2CPP is going to bring AOT essentially to all platforms if I understand it correctly.
This means that a lot of assets that don't work on iOS currently will likely break on all other platforms and have to be updated. My asset is a good example... I'll have to do some serious cleanup to support all platforms once IL2CPP is implemented. It's best to sit back and wait until it is mature and ready to be deployed across platforms.
I'd really like to see it for Android also - for both the piracy and the performance benefits. iOS has always had the AOT performance advantage, Android really feels like the ugly step child here, left out alone in the cold
As an option, not a mandatory target.
Those who can live with the AOT limitations (myself - selfish me ) could have the option to use it today if it was available.
IL2CPP is perfectly usable in its current form for most of my projects, I see no reason to not have it as an option - except for the additional workload for Unity staff - that said though, to some degree it's probably just the compilation that needs to be handled, I'd assume the IL2CPP core is mostly compatible for all native platforms (I'm making a lot of assumptions there).
Me too... close-to-native script performance on desktop opens up some interesting opportunities for app creation.
Yes, I would. I want a runtime, that is stable, where I don't have to work around a broken memory management implementation and that delivers good performance results.
No asset in the world will save me the time, this could save me down the road and I want to learn how to use it properly and test it as soon as possible, so I can rely on it, once it is finally released as stable. For me, this is by far the most important upcoming change in Unity. No PBR and lighting improvement can ever help me to avoid development time loss and quality problems because of uncontrollable FPS drops, quirky behaviour and workarounds, just because the runtime does not execute my realtime game logic in an efficient, controllable and predictable way.
Well for me that is the issue... it's not yet completely stable. Once it is, then I'll be all for pushing it as an option for all platforms.
I'm receiving an error at seemingly random points on iOS IL2CPP using 4.6.3p4.
libc++abi.dylib: terminating with uncaught exception of type std::logic_error: basic_string::_S_construct NULL not valid
Spoiler: Call Stack
#10 0x39300d4c in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) ()
#11 0x0399acf4 in il2cpp:s::Messages::FromCode(il2cpp:s::ErrorCode) at /Users/builduser/buildslave/unity/build/Tools/il2cpp/il2cpp/libil2cpp/os/Messages.cpp:1877
#12 0x039926ac in il2cpp::icalls::System::System::ComponentModel::Win32Exception::W32ErrorMessage(int) at /Users/builduser/buildslave/unity/build/Tools/il2cpp/il2cpp/libil2cpp/icalls/System/System.ComponentModel/Win32Exception.cpp:29
#13 0x01a3c0a8 in Win32Exception_W32ErrorMessage_m48999(Object_t*, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_System_2.cpp:42671
#14 0x01a3c0e8 in Win32Exception__ctor_m48992(Win32Exception_t9264*, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_System_2.cpp:42584
#15 0x01ac6b6c in SocketException__ctor_m42170(SocketException_t5060*, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_System_4.cpp:29415
#16 0x01ac602c in Socket_Receive_m50041(Socket_t3234*, ByteU5BU5D_t241*, int, int, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_System_4.cpp:22569
#17 0x01ac5a80 in NetworkStream_Read_m49983(NetworkStream_t2846*, ByteU5BU5D_t241*, int, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_System_4.cpp:14312
#18 0x02463780 in VirtFuncInvoker3<int, ByteU5BU5D_t241*, int, int>::Invoke(MethodInfo*, void*, ByteU5BU5D_t241*, int, int) at /targets/ios/xcode/Classes/Native/GeneratedVirtualInvokers.h:86
#19 0x01e577c0 in Streams_ReadFully_m41592(Object_t*, Stream_t330*, ByteU5BU5D_t241*, int, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_13.cpp:36962
#20 0x01e57730 in Streams_ReadFully_m41591(Object_t*, Stream_t330*, ByteU5BU5D_t241*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_13.cpp:36945
#21 0x01c37f40 in TlsUtilities_ReadAllOrNothing_m38970(Object_t*, int, Stream_t330*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_10.cpp:73542
#22 0x01c37a1c in RecordStream_ReadRecord_m38447(RecordStream_t7377*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_10.cpp:24034
#23 0x001f18c8 in VirtFuncInvoker0<bool>::Invoke(MethodInfo*, void*) at /targets/ios/xcode/Classes/Native/GeneratedVirtualInvokers.h:20
#24 0x01c44160 in TlsProtocol_SafeReadRecord_m38573(TlsProtocol_t2836*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_10.cpp:36460
#25 0x017198a0 in VirtActionInvoker0::Invoke(MethodInfo*, void*) at /targets/ios/xcode/Classes/Native/GeneratedVirtualInvokers.h:9
#26 0x01c43f74 in TlsProtocol_ReadApplicationData_m38572(TlsProtocol_t2836*, ByteU5BU5D_t241*, int, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_10.cpp:36419
#27 0x02463780 in VirtFuncInvoker3<int, ByteU5BU5D_t241*, int, int>::Invoke(MethodInfo*, void*, ByteU5BU5D_t241*, int, int) at /targets/ios/xcode/Classes/Native/GeneratedVirtualInvokers.h:86
#28 0x01c6d720 in TlsStream_Read_m38901(TlsStream_t7395*, ByteU5BU5D_t241*, int, int, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_10.cpp:70810
#29 0x02463780 in VirtFuncInvoker3<int, ByteU5BU5D_t241*, int, int>::Invoke(MethodInfo*, void*, ByteU5BU5D_t241*, int, int) at /targets/ios/xcode/Classes/Native/GeneratedVirtualInvokers.h:86
#30 0x01c6d7b0 in TlsStream_ReadByte_m38902(TlsStream_t7395*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_TcpClientImplementation_10.cpp:70820
#31 0x02463168 in VirtFuncInvoker0<int>::Invoke(MethodInfo*, void*) at /targets/ios/xcode/Classes/Native/GeneratedVirtualInvokers.h:20
#32 0x003a4e58 in HTTPResponse_ReadTo_m5924(Object_t*, Stream_t330*, unsigned char, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_Assembly-CSharp-firstpass_8.cpp:124084
#33 0x003a39b4 in HTTPResponse_Receive_m5916(HTTPResponse_t1403*, int, bool, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_Assembly-CSharp-firstpass_8.cpp:123314
#34 0x003ab0d0 in VirtFuncInvoker2<bool, int, bool>::Invoke(MethodInfo*, void*, int, bool) at /targets/ios/xcode/Classes/Native/GeneratedVirtualInvokers.h:64
#35 0x00387160 in HTTPConnection_Receive_m5682(HTTPConnection_t1474*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_Assembly-CSharp-firstpass_8.cpp:101093
#36 0x0037fbc0 in HTTPConnection_ThreadFunc_m5680(HTTPConnection_t1474*, Object_t*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_Assembly-CSharp-firstpass_8.cpp:99888
#37 0x0240c454 in ParameterizedThreadStart_Invoke_m58374(ParameterizedThreadStart_t2824*, Object_t*, MethodInfo*) at /targets/ios/xcode/Classes/Native/Bulk_mscorlib_10.cpp:22017
#38 0x0278d2ec in RuntimeInvoker_Void_t102_Object_t(MethodInfo*, void*, void**) at /targets/ios/xcode/Classes/Native/GeneratedInvokers.cpp:45754
#39 0x039bce18 in il2cpp::vm::Runtime:elegateInvoke(Il2CppDelegate*, void**, Il2CppObject**) ()
#40 0x03990c60 in Thread::Thread() ()
#41 0x0399b9fc in Thread::RunThreadWrapper(void*) at /Users/builduser/buildslave/unity/build/Runtime/Threads/Thread.cpp:48
#42 0x039a6dcc in il2cpp:s::ThreadImpl::ThreadStartWrapper(void*) ()
#43 0x395ffe92 in _pthread_body ()
#44 0x395ffe06 in _pthread_start ()
#45 0x395fdb90 in thread_start ()
I don't get your objection to it being available as an option - the sooner it is available as an option the sooner it will be completely stable, the more devs using it and on more platforms will highlight issues that need resolving - ie, it will never be sufficient quality until after it's been available for all platforms.
And like I mentioned before - for those who it is stable enough for right now can take advantage of it.
I would understand your objection if it were to be the only option, but that's not what we're discussing here.
Actually there is work that has to be done per platform. It's not like flipping a switch and turning it on. While it is awesome, there are still significant issues on the two platforms it is currently on. Opening it up for all platforms would require significant development effort as well as diluting the support pool for IOS which needs to stabilize. More bug reports isn't always better. I prefer the take it slow and do it right approach not the cram it in now and fix it later approach. I guess my development experience has always followed the "Do it right, not fast" motto.
il2cpp need more memory than Mono 2.x, iPad mini crash often by low memory when use il2cpp. how to optimization of memory
We don't have any recommendations for memory optimization now. However, if you can submit a bug with your project so that we can compare memory usage, that you help us out. Thanks.
i send bug (Case 686061) with demo ,demo run iPad mini crash neither il2cpp nor Mono2.x, but il2cpp very fast
Thanks, we will investigate.
Before I ask my questions, I have to say that my biggest concern is to be able to code on latest C# version. Oh boy! I want to be able to use these new language features which are listed here https://github.com/dotnet/roslyn/wiki/Languages-features-in-C#-6-and-VB-14. Especially the "nameof" keyword is amazing. I waited for it for like 10 years.
Q1) Since IL2CPP takes place after IL code is generated, I think the limitation of upgrading to latest C# version comes from mono compiler and switching to IL2CPP won't solve this issue. So rolling out the IL2CPP to all platforms will not bring a solution to C# upgrade issue. Am I right?
Q2) What kind of technology change(or improvement) will make Unity's C# version to be upgraded?
Q3) What is the priority of upgrading the C# version for Unity team? Can we can it in 1-2 years or 5-10 years? I know it's impossible to estimate. I just want to know about the intention of Unity team.
I think you missed the link in the first post in this topic. http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/
This is dependent on Mono in order to support compilation on other platforms (such as Mac). Once Microsoft finishes open sourcing everything, it's possible we may see Unity even implement their own abstraction on top of the Microsoft compiler which would allow easier version upgrades. Regardless, until everything is upgraded to IL2CPP and it is able to support the new platform features, we won't be seeing C# 6 in its entirety.
I read it months ago but I forgot its details. Thank you for reminding me.
Ok so, is the problem is all about mono AOT compiler licence? If Unity didn't have AOT players (like iOS), would it be easy to upgrade the mono version? That's (along with performance improvements) why they are implementing IL2CPP, right? To be able to get rid of this mono AOT licence.
IL2CPP solves a number of problems for us.
Licensing - yes, we like to have full control of something so integral as our scripting engine
Portability - WebGL would not have been possible without IL2CPP. In additional, IL2CPP ports to new platforms in a matter of days (our experience so far)
Performance - IL2CPP allows us to have essentially the same performance as hand writter C++. There are cosntraints to be compatible with .Net, but we are looking to only make these constraints cost performance if the user wishes to support them
Miscellaneous - easier to debug the generated code, faster to make features work across architectures, accessible scripting engine for any C/C++ developer, etc.
You knocked it out the park with that, joncham. Exciting stuff.
Does that mean we get a public C/C++ API for Unity??? That would be awesome.
No. And why would it be awesome? Can you give one good reason to use C++ over C# other than performance stuff (which is already addressed by IL2CPP).
Personally I'm a c# developer and have little interest in c++, however for portability reasons I could see where it might be beneficial... being able to use existing c++ code as well as c#.
No, he meant scripting API. Like calling your script methods, creating managed objects from C++. You can do this with Mono today.
- Template meta programming (no C# generics are like a toy compared to what you can do in C++)
- Much larger ecosystem with libraries for basically everything (I know many libs I would love to use in Unity games that don't exist for .NET)
- Can be integrated into almost anything (lets say I want to use my game's systems in another engine or even with my own custom engine, much easier if the game's systems are done in C++)
- Much more cross-platform
- Explicit resource management
Also, IL2CPP may gives the C# code better performance, that in no way means that it is as fast as custom C++ code, just that it is faster than if run in .NET.
Judging from the callstack alone, I think this is fixed on our current development version -- both the crash in Messages::FromCode as well as the SocketException leading to the error code lookup in the first place. The respective changes *may* already be in 4.6.4p1 (sorry, haven't checked). If not, they'll be in the patch release after that.
You mention that "IL2CPP ports to new platforms in a matter of days". Does that mean we should expect IL2CPP later this week for PC?
We have it working for PC internally for development, debugging, and testing. In fact, desktop was the first platform for IL2CPP if I recall correctly.
We'll probably ship IL2CPP on desktops someday, with the option to continue using mono there as well. The main issues are:
Desktops are currently a JIT platform. IL2CPP would bring AOT restrictions with it.
Compilation requires the platform toolchain and compilers. Currently you can performa a build for any desktop on Mac or Windows (i.e. build OSX Standalone on Windows) since we just compile the managed assemblies. Similar builds with IL2CPP will either require cross compilers, or perhaps a nice integration with Unity Cloud Build.
Would it be possible for you guys to add UNITY_IL2CPP as a symbol when you start rolling it out to additional platforms? There is a lot of code out there (my asset being a huge example) that rely heavily on precompiler directives to build different bits of code for different platforms, in my case and many others because of those AOT restrictions. It would be nice to be able to pre-plan for it being rolled out to other platforms and have code ready that should pretty much "just work" when the switch is flipped. Also, if Mono will still be an option, we'll need to be able to conditionally support either IL2CPP or Mono for those platforms.
Currently ENABLE_IL2CPP is defined if an IL2CPP based build is being performed. However, this is really just an internal define that has leaked out. I'll look into defining a more official UNITY_IL2CPP or something like that and communicate when it's been done.
Hey guys, I currently meet serious memory problems with IL2CPP. Our project runs stable on iOS x86 building with mono while crashes very soon on iOS x64 builing with IL2CPP. The problem always due to the 'virtual memory exhausted', which I really don't have any thing to do with. Out VM usage is up to 1G and continues to increase when runing while our actual memory usage is kept under 220M. The crash usually happened when Resources.UnloadUnusedMemory is called.
So, could it be related to IL2CPP? Can I count on the next Unity3D release patch?
Any ETA for the IL2CPP support on PC? The sooner it is available (as an option, of course) the better, as 3rd party assets makers will have the time to upgrade their code.
More than for a performance boost, I'm waiting for IL2CPP for security reasons. I think that IL2CPP is the minimum acceptable for protecting my code.
Yes please, and for Android - this is sorely needed... (as an option).
How big performance boost can we expect for PC builds with IL2CPP? Is it some small margin range like 5-10% or maybe much more?
Just asking generally.
Quote from the blog post:
Is there a list .net things that are not yet supported in il2cpp? (a google sheet would be ideal, progressively remove them so we can quick search)
Okay, you guys have been trying to implement your own IL2CPP on your own, thumbs up for that, its a very ambitious task which could lead to nice results in the future.
However, you are trying to do it without any help from Microsoft (I assume, maybe I'm wrong) nor the open source community.
So far I have seen many people complaining about the current state of the tools, still one year after being announced, plus there is no apparent sign that this tool will be available to other platforms any time soon despite being overly anticipated.
On the other hand it exists, since the creation of the .NET foundation, a project which has similar ambitions, I mean LLILC, a tool which compile IL to LLVM, an intermediate state in C++ compilation, which would allow to port C# to many platforms with native performance just like IL2CPP.
The essence of the .NET foundation is its open source community, which has been very active since its creation.
What I'm saying is that instead of staying in your corner producing mediocre softwares, would it not make sense to join the .NET foundation so that this project could be backed up by the super-enthusiast open source community ?