Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[Official] The collected il2cpp forum topic.

Discussion in 'General Discussion' started by RalphH, May 20, 2014.

  1. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    You say this as if a) a year is an unreasonable amount of time for this kind of development and b) the other project is necessarily better for Unity's specific needs.

    If they were to start now I'd agree, take advantage of existing work. But they aren't starting now. They started this quite some time ago, long before the .NET Foundation stuff was an option.
     
  2. mat_muze

    mat_muze

    Joined:
    Mar 17, 2015
    Posts:
    31
    Right, so it has started long time ago, even before being announced, am I the only one thinking this has taken waayyy too much time (cost/benefit still null after all this years) and that some measures ought to be taken, now that the .NET foundation is here and might help improving the tool?

    There is a whole lot of people in the .NET foundation caring about making C# a better language, I just think its time for Unity to contribute since a great part of its success is due to C#...

    Well I don't expect people at UT to care about my opinion, but I guess it just feels good to talk about your frustrations sometimes.
     
    Last edited: May 7, 2015
  3. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    The benefit isn't "null" at all. It's already running on iOS for the vast majority of people, and if it wasn't running on iOS people wouldn't be able to release Unity titles since February at all. Are you suggesting that delaying for the .NET Foundation version (which, again, was unknown at the time) would have made that situation better?

    Imagine the frustration come February if you were an iOS Unity developer and Unity had just been sitting around waiting for someone else to solve the problem...
     
  4. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Yes, IL2CPP works quite well right now (also WebGL, not only iOS). Throwing it all out and starting over with something "better", instead of fixing the last 0.5%, seems highly inadvisable. That way leads to Duke Nukem Forever.

    --Eric
     
    angrypenguin likes this.
  5. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    Oh it will be available on other platforms. And it's not that far away, even. For example, that's the only scripting backend that's gonna be available for the new Nintendo 3DS.
     
  6. mat_muze

    mat_muze

    Joined:
    Mar 17, 2015
    Posts:
    31
    This was posted on the front page yesterday, do you call a technilogy usefull when developers are not able to publish their titles ?

    From a user:
    “Are there plans to move to .NET Core instead of Mono?” – I really don’t understand why they don’t focus their time on that. IL2CPP has been a complete disaster for me and my team. We have missed iOS launches and deadlines for ~3-4 months now.

    -It takes literally takes more than 10 minutes to compile.

    -The build size is massive….EVEN FOR A PRACTICALLY EMPTY PROJECT.

    -There are still bugs…Still. Yes the dev team is doing a great job at fixing them. But at this rate we are going to see this kind of crap every time apple updates their iOS. Plus I can’t imagine actually being able to support later versions of .net.
     
  7. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Please stop to search for argument against IL2CPP just for the sake of it. It is very new technology, they know what they are doing and they had to support iOS because of Apple very fast. It is not perfect yet, but with every update that happens weekly, there are huge steps forward.
     
  8. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    That does mean no one is able to publish a project. Yes the built time is slow and size larger than before but for the most everything works.

    I don't actually understand what are you exactly after? what is your realistic solution or alternative for iOS or WebGL if they would have to switch now compared to what they have done now?
     
    angrypenguin likes this.
  9. matmuze

    matmuze

    Joined:
    Jan 14, 2014
    Posts:
    27
    I'll tell you what I am exactly after, after all Unity is my daily working tool, and I feel that I am right to complain, here we go:

    Before IL2CPP, Unity users were not able to compile to IOS 64bits anymore, well let them have the latest mono then, problem solved, yes it needs a licence, but after all IOS is a huge business and many people are making big profits out of it.

    No instead Unity decided "flip this, we will change the world", and there we have it, IL2CPP, boom !, "Its quite buggy but well hey it does not matter, we did it, hurray !". Good job, although it has probably cost millions but well, thumbs up.

    Now what upsets me is to learn that all platforms will eventually support it one day (might be in years though no one really knows), and that it is our only exit door from the current and obsolete mono used in Unity. Especially since I am mostly a desktop user this frustrates me a little.

    I think this approach is wrong, just look at the paradox3D engine (a cross-platform Unity-like C# engine), although beta, already supports the latest mono (and also latest .NET for desktop). It will even allow very soon compilation with .NET native, offering C++ performance on windows platforms... and for IOS well you need to buy a Xamarin licence...

    What did they did right ? They focused on coding a game engine, and used the best technologies available, instead of reimplementing the wheel.

    Why can UT just not do the same, I mean if they were caring about what users really need it would have been done it long time ago...

    I'm done I said it all, no matter what explanation you guys bring up now, it will still not change my current state of frustration for not having the latest state of the art technologies that Unity and us deserve.
     
    Last edited: May 7, 2015
  10. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Again, it is very new technology with a huge potential! And again, it was at first created for WebGL, but they had to push because of iOS 64 bits. Yes, it is not yet perfect, but it is improving and already what is currently in 5.1 beta is absolutely impressive!
    Let's just assume that Unity would have switched to a newer Mono version. They would have spent a lot of money for the license, all that money would not be available for any other development. On top of that, it would have been required to integrate the newer version into Unity. For iOS 64 bit, it would have been done very fast due to the time constraint. I believe it is naive to assume that a 64 bit Mono would right now be in a far better shape than IL2CPP.
    IL2CPP seems to save money as well for the porting according to Unity. Porting Mono to another platform was a major undertaking and that is now a lot smoother thanks to IL2CPP. If I remember correctly hat was mentioned in the previous Unite conference.

    They started IL2CPP quite some time ago and it was already mentioned several times, all that new open source .NET technology was not announced then. And this new technology doesn't help right now and it would not have solved the iOS 64 bit issue.
    It would not be very professional from Unity to just jump on board and start to integrate all those new packages just for the sake of it. Unity works on a lot of platforms and they have to make sure that is still possible without breaking all the content that was created.
    The first step they are doing now is to support IL2CPP on more platforms. After that, they will be able to update the .NET version and before those steps are finished, they will now what the next steps will be. I am sure they will have a close look at what is available from the .NET Foundation, but right now, it would be naive and stupid to announce anything.
     
  11. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    You mean some users are not able build 64bit release? are you an iOS dev yourself or are just saying facts based on random user reports?

    In your post you are also suggesting that everyone doing iOS should start paying monthly fee for Xamarin even if they make no profits and just want use the personal edition for fun (paradox example). It's been said many times already that mono will be updated at some point. If you have looked here or elsewhere that mono has been huge time taker for each platform and with IL2CPP it been said to very small effort to support new platforms. Don't forget the amount of platforms there are to be supported and what is possible to support with current mono or .net without IL2CPP.
     
  12. matmuze

    matmuze

    Joined:
    Jan 14, 2014
    Posts:
    27
    You read me wrong, I rather meant that "without" IL2CPP user are not able to publish to IOS 64bit, and my answer to that was to let them user the latest mono with a Xamarin licence...just like paradox3D is doing.
     
  13. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Which would require a lot of changes from Unity to make Mono's 64 bit version run in Unity, next to the existing one. Do you really believe that would be more stable right now?
     
  14. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    Why do you assume that the alternative wouldn't also have issues? Even swapping to MS .NET isn't a golden bullet - I wasn't effected myself but I hear that people went through their share of issues when swapping over to that for Windows Store support.

    So are we ignoring the fact that Paradox is an open source engine and thus probably has different licensing concerns and requirements to Unity?
     
  15. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    276
    To everyone who is having problems getting your project running on iOS with IL2CPP we do understand your frustration. We are working very hard to fix bugs as they are reported. We are rapidly dealing with build size issues making incremental improvements in each (patch) release.

    Please make sure you report bugs. I know users are frustrated when you app works on Mono, and not once you switch to IL2CPP. And you think it should be obvious that we should fix the issue. But, many people are shipping projects with IL2CPP. We have extensive tests running on IL2CPP. So please report issues you want fixed.

    We have no announcements at this time but know that IL2CPP is delivering on many of our hopes for it. Platforms are easily ported to and up & running robustly pretty quickly. Definitely much faster than Mono ever was for us by far.

    There is a ton of things going on in the .Net space right now. We are following all these items just like you are. We do not have our heads in the sand. We are continually collaborating with Microsoft and others. For example the announcement from Microsoft today: http://blogs.windows.com/msedgedev/2015/05/07/bringing-asm-js-to-chakra-microsoft-edge/ Note they are discussing benchmarks from Unity running IL2CPP converted code.

    Something like LLILC is very interesting yes. But it is still very young. The FAQ indicates it only supports AMD64 as an architecture and that OS X and Linux support are shaky at best. That doesn't mean we are ignoring it, just that any usefulness seems to be some indeterminate amount of time from now.

    For another example, 'upgrading .Net' is not a simple task. Not just due to internal technical factors for us, but because we know it will impact all our users. Understand that IL2CPP is a new scripting engine, but we are using the same class libraries as Mono. And the same tools (e.g. C# compiler). That gives us a fairly limited scope for bugs and problems. Upgrading Mono will bring years of changes to the runtime, C# compiler, *and* class libraries, breaking behaviors, a potentially incompatible profile update, etc. It will mean running the new mono VM on platforms and architectures where it is not commonly run (or even built); e.g. not many people are running Mono on Windows other than Unity. We have put lots of thought into properly managing the risk vs. reward in how we migrate forward.

    Finally, I want to make sure it's clear that we are very much focused on enabling you to ship your projects. We have prioritized IL2CPP as such. We initially were aiming for correctness, now build size, and ever more performance optimizations in the future. We are very aware that hundred of thousands (or millions) of developers are depending on our product. We have tried to convey how IL2CPP acknowledges that reality. How it allows us to best support what is approaching 2 dozen platforms with parity and performance. How it has orders of magnitude less architecture and platform specific code than Mono which we need to port, debug, and maintain. How it will enable us to upgrade to .Net across all platforms in a reasonable amount of time. How it enables Unity in unique and constrained environments like WebGL and the recently announced New 3DS XL. IL2CPP is a very integral piece of a larger plan to achieve our goals (newer .Net, platform support and parity, high performance .Net for games) given the constraints we operate under.

    Thanks.
     
    Sebioff, Paulohmm, Moonjump and 8 others like this.
  16. Bowie-Xu

    Bowie-Xu

    Joined:
    Sep 14, 2011
    Posts:
    28
    Hi
    Maybe I fired it in wrong place here but I can't find IL2CPP category in Unity Bug Reporter tool(It only have "A problem with editor" and "A problem with player" and I think my situation belongs none of these two). You guys can move it to anywhere it should be.

    What I want to do is trying to use Moonsharp (C# interpreter for LUA) with IL2CPP backend. It has a testbed project for Unity. Within this project, we have "MoonSharp.Interpreter.dll" and "nunit.frameworkd.dll" which I believe are all IL dll.

    The xcode reports many errors when I try to compile project.


    I also tried WebGL platform. This time, unity just report an error directly:



    Seems IL2CPP parsing copyright information in the wrong way by adding extra newline control character. I know that I can make it right by modifying the source code because MoonSharp is open sourced. But maybe next time I will use another IL DLL without source code.

    My unity version is 5.0.1 p4 personal and Xcode version is 6.3 under Mac OS X 10.10.3.

    Again, sorry for placing it in wrong place.

    Thanks.
     

    Attached Files:

  17. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    @Bowie Xu,

    that, would be a problem with a player. Please, report a bug through the bug reporter.
     
  18. matmuze

    matmuze

    Joined:
    Jan 14, 2014
    Posts:
    27
    What about having one branch of Unity which you support all the basic platforms, where the latest version of Mono is guaranteed to run smoothly out of the box, just like in Paradox3D for instance.

    And another one using IL2CPP which would include the previous platforms, plus all other exotic platforms such as WebGL, 3DS XL, whatever.

    The only difference would lie in the compilation internals, but it would at least allow users to use state-of-the art C#/.NET, for those that really need it...

    Call me crazy maybe for requesting such thing, but at some point people will start to look elsewhere for what there truly need...

    Although I salute the efforts for enabling their wide-range multi-platform vision, not everybody is interested in WebGL, 3DS XL and the like...
     
  19. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Didn't enough people explain to you about Unity's plan regarding a .Net version update? There is no reason to bring this topic up in multiple threads! A Mono update was requested by the community long ago, now there is a official plan about it. A single person asking for an update won't change anything, welcome to the reality!
     
  20. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    iOS isn't exactly "exotic", it's one of the core platforms. And WebGL is too, since the webplayer is on the way out.

    --Eric
     
  21. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    You missed the earlier comments. He did not list iOS cause it's supported in mono and everyone can pay the license themselves if they want to publish for iOS.
     
  22. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    And there goes building to iOS for free out of the window :).
     
  23. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    Not a problem, like he said "yes it needs a licence, but after all IOS is a huge business and many people are making big profits out of it." :rolleyes:
     
  24. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Thankfully, it is not one of the goals of Unity to democratize game development... :)
     
  25. mat_muze

    mat_muze

    Joined:
    Mar 17, 2015
    Posts:
    31
    I dont know why but I feel that by the time IL2CPP will be commercially available and stable on every platform, .NET will already be compling in native on every platform... But that even then, UT would still not do the switch because Unity would be too untangled with IL2CPP.

    Do people really think that IL2CPP will outperform .NET in the end ? I mean come on...
     
  26. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    It's not as far out as you seem to think, since Unity can optimize for far more specific and/or relevant use cases than the general .NET team can.

    Out of interest, have you developed large scale software and/or non-trivial development tools or pipelines before? The fact that there are shared core concepts and/or underlying technologies does not mean that moving from one to another is a "switch" Unity can make on a whim, even if it did turn out to be a better solution.

    What's more, if it does turn out to be a better solution in the long run then I'm confident Unity will make the move when the time is right. They've done it with things before, I'm sure they'll do it with things again.

    Of course if you don't trust that then you can go roll your own game engine that supports whatever platforms you need, built on the latest .NET and all its cross platform tools, right now. Why waste time whinging about the tools here if the tools elsewhere are so much better?
     
    Ostwind likes this.
  27. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    It seems that the people who are working for Unity are just a bunch of idiots in your head. If I were you, I would rather sooner than later change to something else and hope the same doesn't happen there.
     
    Ostwind likes this.
  28. mat_muze

    mat_muze

    Joined:
    Mar 17, 2015
    Posts:
    31
    Well if Paradox3D gets mature enough one day, I might make the jump.

    And I guess that if there was a good Unity clone with modern C# scripting already available out there, then all of you guys might also consider switching too, I guess, unless you are really turned on by archaic C# scripting...
     
    Last edited: May 13, 2015
  29. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    Unity is aware of that issue and is working on it, to get modern C#. It is pointless to ask them to do something they are already working on and telling them to do it differently just to get what you want.
    We want a new C# as well, you are not alone with that.
     
    angrypenguin likes this.
  30. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    Yeah, if there were better tools out there of course we'd consider switching. That's the point. There aren't*.

    Nobody is saying Unity is perfect, but the fact that even you won't jump to other tools at the moment says that Unity must, on the whole, be the better alternative if you consider more than just the one flaw you're focusing on.

    * Broadly speaking. There are certainly competitive options and/or different approaches, just nothing which is clearly and broadly "superior" at doing what Unity does.
     
  31. serpin

    serpin

    Joined:
    Nov 13, 2011
    Posts:
    54
    My 50c:
    1. I've noticed that performance of the Animator component decreases with IL2CPP compared to mono. I've clocked it to be at least 20-50% slower (for scenes with a lot of animators especially). Using IL2CPP for some reason leads to more performance spikes for (seemingly) no reason. Mono build doesn't display such behavior, but then again - it is overall more performant when it comes to using animators.
    2. I also found out that performance of the Shuriken particle systems is somewhat slower compared to mono builds.
    3. Since it takes a lot of time to compile and link a bunch of CPP files each time, here's the question I've been meaning to ask for a long time: is it possible to only compile IL2CPP "VM" for each architecture (that is everything that's considered a part of the "VM" which user scripts run in) once or have it shipped with Unity like mono binary is shipped? This way you could do as much optimization as possible for the VM once and then only convert/compile user scripts each time. I don't have problem with Unity taking longer to "postprocess player" since I understand that turning IL to CPP is no easy task, but I do miss fast build times of the mono player. I'm not familiar with IL2CPP internals so I'm sorry in advance if something I propose here is incredibly stupid.
    4. Previous question brings me to the other one: you mentioned that there were plans to allow to build IL2CPP desktop builds to test out possible errors and profile/iterate quicker without the need to build for the device each time. Do you have any ETA on this? Profiling on the device is nice and all, but I noticed that some of the user-written classes that work flawlessly on mono builds don't function at all on IL2CPP ones at all, and having to constantly build/compile/transfer to the device to test each change is quite cumbersome and time-consuming.
    5. Do you have any data on how much faster/slower IL2CPP is when it comes to marshalling?
    Cheers.
     
    Evgeny-Eliseev likes this.
  32. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    276
    First, please make sure you are building in Release for all performance analysis. This matters very much for IL2CPP.
    1. Please file a bug
    2. Similar. These issues #1 & #2 should not be the case. Again make sure you are in Release when building in Xcode.
    3. We do this already (ship the VM as a static library). However, we know build times are a pain and are actively working on improvements.
    4. No ETA. We are working on other platforms now, but Standalones are not at the top of the list.
    5. I have not done tests, but being familiar with the architecture of both I would expect them to be similar. If this is not the case please let us know.
     
  33. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    642
    As an iOS developer, memory usage is more important than performance right now.

    People are seeing System.ExecutableAndDlls taking up to 135MB in the profiler in IL2CPP builds (although I've not seen/done direct comparisons with Mono builds yet)

    But that is more than half of the memory available to an app on a 512MB iOS device (if you go much over 250MB, you're looking at an out-of-memory crash)
     
  34. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    276
    Understood. I am actively working on this now. I see IL2CPP using ~20% more RAM at runtime versus mono and already have some fixes underway to alleviate this.
     
    angrypenguin likes this.
  35. nextory

    nextory

    Joined:
    Mar 11, 2013
    Posts:
    1
    Hi,

    I encountered EXC_BAD_ACCESS in TransformVertices_Strided_XYZ when IL2CPP Arm64.
    And I found a solution, Dynamic Batching is off.
    However, I use -batchmode with Jenkins in this project.
    So, I want to know how to turn 'Dynamic Batching' off from scripts.
    I tried the following, but it did not work.
    PlayerSettings.SetPropertyInt("DynamicBatching", 0, BuildTargetGroup.iPhone);

    Please let me know how to solve it.
    I use Unity 4.6.5p1.
     
  36. chubbyWeavil

    chubbyWeavil

    Joined:
    Apr 2, 2013
    Posts:
    2
    Hey guys! I'm loving the performance gains from IL2CPP, great work overall I must say.

    One thing I can't seem to find is how to configure the iOS Scripting Backend from code, is that possible? I'd like to be able to turn it on and off for continuous integration builds. I was hoping it was some property of PlayerSettings but I don't see it here:

    Code (CSharp):
    1.     public sealed class iOS
    2.     {
    3.       public iOS();
    4.  
    5.       public static string applicationDisplayName { get; set; }
    6.       public static bool exitOnSuspend { get; set; }
    7.       public static bool prerenderedIcon { get; set; }
    8.       public static bool requiresPersistentWiFi { get; set; }
    9.       public static ScriptCallOptimizationLevel scriptCallOptimization { get; set; }
    10.       public static iOSSdkVersion sdkVersion { get; set; }
    11.       public static iOSShowActivityIndicatorOnLoading showActivityIndicatorOnLoading { get; set; }
    12.       public static iOSStatusBarStyle statusBarStyle { get; set; }
    13.       public static iOSTargetDevice targetDevice { get; set; }
    14.       public static iOSTargetOSVersion targetOSVersion { get; set; }
    15.       public static iOSTargetResolution targetResolution { get; set; }
    16.     }
     
  37. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    276
    For Unity 5:
    PlayerSettings.SetPropertyInt("ScriptingBackend",
    (int)ScriptingImplementation.IL2CPP, BuildTargetGroup.iOS);
    PlayerSettings.SetPropertyInt("Architecture",
    architectureValue, BuildTargetGroup.iOS);

    For Unity 4.6:
    PlayerSettings.SetPropertyInt("ScriptingBackend",
    (int)ScriptingImplementation.IL2CPP, BuildTargetGroup.iPhone);
    PlayerSettings.SetPropertyInt("Architecture",
    architectureValue, BuildTargetGroup.iPhone);

    Where 'architectureValue' is as follows (the enum for architecture seems to be internal currently):
    0 - ARMv7
    1 - ARM64
    2 - Universal
     
  38. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    @joncham
    The big issue I'm having right now is with generic parameters. If the generic parameter is a Boolean, the compiler seems to be converting it to a Byte.

    Here's an example... having the following JSON:

    Code (csharp):
    1.  
    2. {
    3.     "SomeValue" : true
    4. }
    5.  
    If I deserialize that JSON to a JObject (using JSON .NET for Unity)
    Code (csharp):
    1.  
    2. var myObject = JObject.Parse(jsonString);
    3.  
    Now, that JObject will have a property called "SomeValue" and I call an extension method to get that value:

    Code (csharp):
    1.  
    2.   bool result = JObject["SomeValue"].Value<bool>();
    3.  
    That works fine with Mono but pukes with IL2CPP. It works fine in IL2CPP for other types (like string, or int) but fails for bool. The error message makes it appear that the IL2CPP compiler is somehow converting that bool generic type argument to Byte.

    Specifically look at the bolded text. I've had this error reported to me by two users within the last 24 hours. Both users are using 4.6.5p4 but we also verified that this is at least happening on p3 as well.
     
  39. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    276
    Can you please file a bug for this? Also, be sure to include the specific error you are getting as I couldn't determine that from your post above. We do generic sharing for bools and bytes, but the type information should be preserved.
     
  40. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    I'll see if I can get additional information... that's all the information that I was provided. But I do have a simple repro project so I'll get the bug report filed. I wonder if this has anything to do with the fact that some of the methods being called are static extension methods.
     
  41. knr_

    knr_

    Joined:
    Nov 17, 2012
    Posts:
    258
    I understand the type of undertaking something like il2cpp is and appreciate the work being done on it. Yeah, its rough now but man, for those of us who have worked in AAA studios before dealing with C/C++ (and would like to stay far away from it when we are making games now) we really appreciate the effort going into this.

    I also understand that upgrading Mono is not a trivial task, and I don't want to add to the chorus of people asking about it, but I did have a question because I am interested in using a feature that was introduced in .NET 4.x - the dynamic type.

    When the smoke clears and some focus could be directed toward upgrading Mono, would dynamics be supported through il2cpp? I know its a "that is far down the road" question, but just thought I would at least plant the seed now. :)

    Thanks!
     
  42. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    Yes. When Mono gets an upgrade, IL2CPP will get .NET upgrade as well. We aim for parity between platforms, because we want you to make your game once and deploy everywhere: that's not possible if different platforms target different .NET profiles (well, WinRT platforms do, but there's not much we can do about it at this time, and people who work on them knows how much pain this difference makes).
     
    charmandermon likes this.
  43. turbo3d

    turbo3d

    Joined:
    Apr 28, 2014
    Posts:
    50
    Hi,
    Maybe I fired it in wrong place here but I can't find IL2CPP category in Unity Bug Reporter tool.
    Bug is relative to the marshaling of arrays, using native plugins (SVGAssets in this case) and IL2CPP.
    In the detail, arrays passed as output containers to native functions are marshaled differently, according to their elements type.
    See the code below: it shows the produced code for two different native functions (svgtSurfaceViewportGet, svgtSurfaceCopy).
    The difference is that their output arrays (respectively 'viewport', 'dstPixels32') elements are float and Color32.
    Color32 is not a native C# type, and this produces a code that passes a temporary created (and initilized over a slow for/loop) array to the native function, so the original output array is never touched. This seems a bug: if not, could you please clarify how to pass a non-native type array without the creation of additional temporary arrays?

    Code (csharp):
    1.  
    2. [DllImport(libName)]
    3. public static extern int svgtSurfaceViewportGet(uint surface, float[] viewport);
    4. // System.Int32 AmanithSVG::svgtSurfaceViewportGet(System.UInt32,System.Single[])
    5. extern "C" {int32_t DEFAULT_CALL svgtSurfaceViewportGet(uint32_t, float*);}
    6. extern MethodInfo AmanithSVG_svgtSurfaceViewportGet_m67_MethodInfo;
    7. int32_t AmanithSVG_svgtSurfaceViewportGet_m67 (Object_t * __this/* static, unused */, uint32_t ___surface, SingleU5BU5D_t28* ___viewport, MethodInfo* method) {
    8.  
    9.   typedef int32_t (DEFAULT_CALL *PInvokeFunc) (uint32_t, float*);
    10.   static PInvokeFunc _il2cpp_pinvoke_func;
    11.   if (!_il2cpp_pinvoke_func) {
    12.   _il2cpp_pinvoke_func = (PInvokeFunc)svgtSurfaceViewportGet;
    13.   if (_il2cpp_pinvoke_func == NULL) {
    14.   il2cpp_codegen_raise_exception (il2cpp_codegen_get_not_supported_exception("Unable to find method for p/invoke: 'svgtSurfaceViewportGet'"));
    15.   }
    16.   }
    17.   // Marshaling of parameter '___surface' to native representation
    18.   // Marshaling of parameter '___viewport' to native representation
    19.   float* ____viewport_marshaled;
    20.   ____viewport_marshaled = il2cpp_codegen_marshal_array<float>((Il2CppCodeGenArray*)___viewport);
    21.   // Native function invocation and marshaling of return value back from native representation
    22.   int32_t _return_value = _il2cpp_pinvoke_func(___surface, ____viewport_marshaled);
    23.   // Marshaling cleanup of parameter '___surface' native representation
    24.   // Marshaling cleanup of parameter '___viewport' native representation
    25.   return _return_value;
    26. }
    27. [DllImport(libName)]
    28. public static extern int svgtSurfaceCopy(uint surface, Color32[] dstPixels32, int dilateEdgesFix);
    29. // System.Int32 AmanithSVG::svgtSurfaceCopy(System.UInt32,UnityEngine.Color32[],System.Int32)
    30. extern "C" {int32_t DEFAULT_CALL svgtSurfaceCopy(uint32_t, Color32_t27 *, int32_t);}
    31. extern MethodInfo AmanithSVG_svgtSurfaceCopy_m66_MethodInfo;
    32. int32_t AmanithSVG_svgtSurfaceCopy_m66 (Object_t * __this/* static, unused */, uint32_t ___surface, Color32U5BU5D_t26* ___dstPixels32, int32_t ___dilateEdgesFix, MethodInfo* method) {
    33.  
    34.   typedef int32_t (DEFAULT_CALL *PInvokeFunc) (uint32_t, Color32_t27 *, int32_t);
    35.   static PInvokeFunc _il2cpp_pinvoke_func;
    36.   if (!_il2cpp_pinvoke_func) {
    37.   _il2cpp_pinvoke_func = (PInvokeFunc)svgtSurfaceCopy;
    38.   if (_il2cpp_pinvoke_func == NULL) {
    39.   il2cpp_codegen_raise_exception (il2cpp_codegen_get_not_supported_exception("Unable to find method for p/invoke: 'svgtSurfaceCopy'"));
    40.   }
    41.   }
    42.   // Marshaling of parameter '___surface' to native representation
    43.   // Marshaling of parameter '___dstPixels32' to native representation
    44.   Color32_t27 * ____dstPixels32_marshaled;
    45.   const size_t ____dstPixels32_Length = ((Il2CppCodeGenArray*)___dstPixels32)->max_length;
    46.   ____dstPixels32_marshaled = il2cpp_codegen_marshal_allocate_array<Color32_t27 >(____dstPixels32_Length);
    47.   for (int i = 0; i < ____dstPixels32_Length; i++) {
    48.   Color32_t27  const& item = *reinterpret_cast<Color32_t27 *>(SZArrayLdElema((Il2CppCodeGenArray*)___dstPixels32, i));
    49.   (____dstPixels32_marshaled)[i] = item;
    50.   }
    51.   // Marshaling of parameter '___dilateEdgesFix' to native representation
    52.   // Native function invocation and marshaling of return value back from native representation
    53.   int32_t _return_value = _il2cpp_pinvoke_func(___surface, ____dstPixels32_marshaled, ___dilateEdgesFix);
    54.   // Marshaling cleanup of parameter '___surface' native representation
    55.   // Marshaling cleanup of parameter '___dstPixels32' native representation
    56.   const size_t ____dstPixels32_marshaled_CleanupLoopCount = ((Il2CppCodeGenArray*)___dstPixels32)->max_length;
    57.   for (int i = 0; i < ____dstPixels32_marshaled_CleanupLoopCount; i++) {
    58.   }
    59.   il2cpp_codegen_marshal_free(____dstPixels32_marshaled);
    60.   ____dstPixels32_marshaled = NULL;
    61.   // Marshaling cleanup of parameter '___dilateEdgesFix' native representation
    62.   return _return_value;
    63. }
    64.  
    I expected the marshaling of dstPixels32 argument to be performed in this way in order to work:
    Code (csharp):
    1.  
    2. ____dstPixels32_marshaled = il2cpp_codegen_marshal_array<Color32_t26>((Il2CppCodeGenArray*)___dstPixels32);
    3.  
    Many thanks in advance!
     
  44. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    It might be a bug - but please submit it if you can. Otherwise it will get lost.

    You can workaround it by passing raw pointer to your native plugin:

    Code (csharp):
    1. fixed (Color32* pixelsPtr = dstPixels32)
    2.     svgtSurfaceCopy(surface, pixelsPtr, dilateEdgesFix);
     
  45. TactileGames

    TactileGames

    Joined:
    Oct 6, 2014
    Posts:
    9
    Hi,

    We were wondering what IL2CPP means for the "Fast but no exceptions" option?

    We have upgraded from 4.5.5 to 4.6.6p3 and have noticed that .NET exceptions will no longer crash our game on iOS - e.g. when a NullReferenceException is thrown, then stack unwinding is performed, but something inside the IL2CPP runtime catches the unhandled exception and allows the game to continue running in a, now, invalid state.

    As I understand it, then c++ exceptions are used in the IL2CPP generated code to represent the .NET exceptions. Does this mean that the "Fast but no exceptions" option is now deprecated and the IL2CPP generated code will always perform exception handling instead of crashing the game? (and by extension requiring use of System.AppDomain.CurrentDomain.UnhandledException to catch unhandled .NET exceptions?)

    Best,
    Morten
     
  46. tonydongyiqi1

    tonydongyiqi1

    Joined:
    Jun 30, 2015
    Posts:
    13
    using IL2Cpp instead of Mono(2.x) cause Significantly Reduce Performance。
    There's many Ai pawns in my game. 800+ may be. The script performance in Mono(2.x) build is 30ms cost.
    While In IL2Cpp build,it cost more than 500ms.
    I think there are some bug in Unity IL2CPP cause the decrease of Performance.
     
  47. Schubkraft

    Schubkraft

    Unity Technologies

    Joined:
    Dec 3, 2012
    Posts:
    1,070
    Then please submit a bug report with a small repro scene that clearly shows the issue.
     
  48. larku

    larku

    Joined:
    Mar 14, 2013
    Posts:
    1,422
    Are you doing your build in release mode (XCode) a Debug (Run) (the default) will be debugging the native code - this may have huge performance implications. Change your build target settings via Product->Scheme->Edit or how ever suits your needs.
     
  49. tonydongyiqi1

    tonydongyiqi1

    Joined:
    Jun 30, 2015
    Posts:
    13
    I'm pretty sure i'm using release mode in XCode.
    And test again. Mono2.X build fps is 20~30 fps. But only 2~10fps in IL2CPP
     
  50. tonydongyiqi1

    tonydongyiqi1

    Joined:
    Jun 30, 2015
    Posts:
    13
    where to send repro scene? thank you~