Search Unity

[Official] The collected il2cpp forum topic.

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

  1. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,360
    I wonder if that influenced Unity's decision to not use virtual function calls into MonoBehaviours?
     
  2. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    AFAIK, it did not. Unity implements hot reloading in the Editor via .Net application domains. tl;dr; they are essentially a process within a process. While being 'hot reloaded' in the Editor the application domain state is serialized, torn down, new assemblies loaded, app domain is recreated, and the state deserliazed in the new code/data.

    I forget the reasons to not use virtual functions from the last time we discussed it, but I think it was mainly backward compatibility and performance concerns at this point.
     
  3. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,446
    This seems great for performance but are there plans to improve development iteration time?
    Playing a bit with Scratch for a friend's mini project, I got spoiled with Live scripting.
     
  4. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
    I just want to remind that some of us use JIT for reasons other than just faster compile times, and do want it available outside the editor, so please do continue to offer it as an option in Standalone builds.
     
  5. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    1,531
    Yep, thats pretty much what i'm hoping for, though fully understand it will take time before you get to that stage.
     
  6. HonorableDaniel

    HonorableDaniel

    Joined:
    Feb 28, 2007
    Posts:
    2,903
    I'm trying to visualize what's going on here. So far I've got it down to 2 possibilities. Can someone help me complete the picture; which one is closest/correct?
     

    Attached Files:

    • $1.png
      $1.png
      File size:
      23.8 KB
      Views:
      1,276
    • $2.png
      $2.png
      File size:
      25.7 KB
      Views:
      907
  7. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    #1 (the bottom one)
     
  8. HonorableDaniel

    HonorableDaniel

    Joined:
    Feb 28, 2007
    Posts:
    2,903
    Okay cool, thx.
     
  9. sandboxgod

    sandboxgod

    Joined:
    Sep 27, 2013
    Posts:
    366
    Well that's not true; I've hot reload my C++ changes quite often in UE4. You just cant do it if you've added variables to C++ classes.

    Besides, DLLs can be hot reloaded. UE4 has difficulty due to the nature of their hard coded reflection system. When ue4 runtime starts, it instantiates all the ue4 macro'ed classes. Thus, changing the direct structure of the Class can be risky.

    Has nothing to do with Unity though. It all boils down to how their engine architecture is set up. The issues C++ programs run into with hot reloading will vary. It is difficult to hot reload C++ code but it is for sure possible.

    All that being said- all I care about is seeing IL2CPP coming to pc platforms. I don't care bout the editor. It can remain Mono for all I care atm
     
  10. AngryAnt

    AngryAnt

    Keyboard Operator Moderator

    Joined:
    Oct 25, 2005
    Posts:
    3,042
    I am curious: How unacceptable was your situation yesterday before the IL2CPP announcement vs. after? From your posts it sounds like IL2CPP stole your lunch money.
     
  11. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,003
    This is a solved problem... at least, the team I was technical lead for in 2000/2001. We did game engine development with solely using DLLs for each component of the engine thus DLL hot swapping was no problem. We could even have different versions of the same component DLL in the same folder and hot switch between them. To add i.e. a new texture file format to the engine, we simply dropped a DLL into the game folder. Adding a new physics element, do the same. It's mainly a question of well defined interfaces (on which we spend 6-7 month before we even wrote a line of engine code; prototype code not counting ;) ).

    The biggest problem was the memory management across DLL borders which has been solved by a memory allocation system which itself was enclosed in a DLL (and thus, the DLL was replaceable but we had to restart the app to swap the memory manager).
     
  12. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,360
    Oh, I didn't mean in the coming updates, I meant back at the start when you did it. It just always puzzled me that it does a by-name-lookup or something rather than a virtual function call. And since reloading scripts in the Editor is a super common thing I thought the info Phobic showed could have had something to do with the initial design.
     
  13. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,003
    I've been thinking of this (well it's more like a question to the Devs :) ):

    How is it going to work in the editor? Currently, I simply can hit "Play" and the game starts (even if my target is iOS/Android). How is this managed across editor/target border? Will the editor be automagically be restrained to use the AOT compiler settings of the target platform? Will we see any compile time issues?
     
  14. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,208
    That was answered several times, namely that the editor stays the way it is. (With a newer Mono, eventually.)

    --Eric
     
  15. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,633
    And, to add to that, restraining the editor (even when running in Mono) to give compiler errors for stuff not available in AOT/IL2CPP should be possible, IMO - don't we already do that on iOS?
     
  16. jemast

    jemast

    Joined:
    Dec 7, 2011
    Posts:
    141
    I'm not sure why you're getting so much heat. The present situation was deadlocked and Xamarin looked like a bottomless pit when it comes to licensing. Don't get me wrong, Xamarin does an awesome job with Mono and their paid iOS/Android/Mac toolset. Though I'd much rahter you throw cash at Geomerics, Imagination Tech or other third party game engine tech that moves really fast rather than third-party compiler technology.

    I think you made the right choice for the future, it looks like the benefits will far surpass whatever tradeoffs there will be (not much from my understanding apart from waiting for you to ship it). I'm really enthusiastic. Sure I'll be on the lookout for this to not become DNF-IL2CPP but on my end all I have to say is keep up the good job. :)
     
  17. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,003
    Well sorry... many posts to read :) Thanks anyways :)
     
  18. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,494
    From: http://forum.unity3d.com/threads/245400-Unity-5-Beta-Insights?p=1632818&viewfull=1#post1632818

     
  19. Teo

    Teo

    Joined:
    Oct 31, 2009
    Posts:
    564
    Totally agree here.

    So much effort and problems to keep C# instead removing it completely and going C++ all the way.
     
  20. JasonBricco

    JasonBricco

    Joined:
    Jul 15, 2013
    Posts:
    936
    It's worth keeping C#, for sure. Especially when we can have C# at native speed. I mean, come on. C++ or C# at C++ (or close enough?) speed? Is that a hard one?
     
    JaredThirsk likes this.
  21. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    Lucas vocalized why C# is important to us earlier in this thread. At the same time, having the discussion about C# vs C++ is not really what this topic is for and it's been had many times over on the forums. I'm not sure how re-opening that discussion in this thread and polluting it with that instead of exchanging ideas/information/thoughts about il2cpp makes sense.

    There's a topic here which is maybe more suitable to have this discussion.
    http://forum.unity3d.com/threads/246907-Unity-to-use-C
     
    JaredThirsk likes this.
  22. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    Would this be mean it's less effort for UT to add new engine features (If you wanted to add chipmunk2d support for example) to Unity that are supported across all platforms? ie: did the old mono method require a lot more platform-specific code? Or does it not make much difference to that kind of thing?
     
  23. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    This doesn't affect anything with scenarios with native plugins like chipmunk.
     
  24. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    Sorry, Chipmunk was probably a terrible example :) Still trying to get my head around how it all fits together.

    Can we expect more detailed blog posts over the next few weeks/months?
     
  25. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    (from the blogpost)
    yes ;-)
     
  26. L-Tyrosine

    L-Tyrosine

    Joined:
    Apr 27, 2011
    Posts:
    294
    From what I can see IL2CPP is a great thing, really amazing work.

    Some quick questions:

    Because the nature of .net assemblies, today one can disassemble, recompile and clone a Unity game with little effort (with all site lock/protection code stripped out). I guess the affected platforms are the webplayer and windows builds(?). Then again, I understand that this is not a Unity fault and is a global software development problem. But IMO some defense is better than none (currently I'm using encrypted asset bundles and dynamic assemblies compiled from web servers and that proved enough until now).
    That said, will WebGL/asm.js build improve security in this matter? Is the produced asm.js code hard to decompile?

    Also, what about LINQ? Will it be fully usable (I don't know if it uses dynamic code or fixed expression trees)?

    I understand that dynamic loading .dll assemblies is impossible. But will WebGL/asm.js builds allows some sort of dynamic code load?

    Thanks!
     
  27. TylerPerry

    TylerPerry

    Joined:
    May 29, 2011
    Posts:
    5,577
    Hi Unity folk,

    I'm wondering if someone could try doing a build of KopiLua on WebGL it would be amazing to see if it works with il2cpp. I have nightmares that I won't be able to use a new version of Unity in the future if my projects as I need in app scripting. Or could someone comment on if it would in theory be possible?
     
  28. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,633
    I don't know KopiLua, but I guess for a VM like that, chances are that it would dynamically generate code, which would not work with il2cpp or any other AOT platform. But, simply asked: Does it work on iOS right now? If yes, it will probably work on il2cpp as well.
     
  29. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,494
    KopiLua itself is simply the Lua source code rewritten in C#. Afaik it doesn't make use of any .NET particular features like dynamic compilation. But if you are talking about KopiLuaInterface (I know it can get confusing), KLI is a combination of two libraries: KopiLua and LuaInterface.

    LuaInterface is a C# library, a high-level wrapper for letting .NET objects communicate with a (native) Lua interpreter and back again. It turns out LuaInterface works pretty well with KopiLua too, so the author of KLI combined the two.

    The problem is, LuaInterface indeed uses Reflection.Emit. The good thing is I believe it's not critical, and you can perhaps modify LuaInterface so it doesn't make use of that.

    From http://forum.unity3d.com/threads/124569-Lua-and-Unity?p=1627544&viewfull=1#post1627544

    But if you don't feel the need to use LuaInterface, KopiLua by itself I think will work just fine. It's simply as if you are using the Lua C API, but in C#.
     
    Last edited: May 21, 2014
  30. Jason-Cahill

    Jason-Cahill

    Joined:
    Sep 21, 2013
    Posts:
    1
    I feel like everyone is missing one of the biggest benefits of AOT in this thread: no more need for code obfuscation. C# by it's nature turns into IL that is trivial the decompile... variable names, code structure, and metadata are all littered throughout it. Once you've gone from IL to CPP and to platform specific machine language, you've lost all of that. I know a lot of people think that code obfuscation is unnecessary, but if you are building any sort of MMO where cheating is an issue, being able to see the original source code makes cheats trivial, because you can't hide anything.

    Obfuscation doesn't stop "military grade hackers" by any stretch of the imagination, but it DOES stop script kiddies. it makes the barrier to entry so high that most people will get bored and give up. IL2CPP, like .NET Native is a huge helper if you are trying to protect your game's IP. And, unlike most obfuscation tools, this approach is done "the right way" because it is built by the team building and supporting the product.
     
  31. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    Right, it's a hell of a lot harder to decompile C++. Tools exist, but not many and certainly not user-friendly enough for your average "script kiddie".
    The reason of course is that the compiled native code has absolutely no meaningful variable names or function names. It's not really "obfuscation", it just so happens that compiled native code is not human readable :)
    Unlike IL, where even obfuscation has limited use because only private things can be obfuscated (any UnityEngine references or public fields/methods will be plain text for all to see)
     
  32. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,208
    Yes, as far as I know (e.g. if you switch the editor to iOS then Unityscripts always behave as #pragma strict regardless of whether that's actually in scripts).

    --Eric
     
  33. Ocid

    Ocid

    Joined:
    Feb 9, 2011
    Posts:
    476
    Not exactly what I was expecting.

    Still I'll reserve judgement until I see more blog posts or can try it out on standalone when it comes to that. WebGL is out of the question for me :)
     
  34. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    Will all these changes (new mono, IL2CPP for all platforms) be released in a 5.x version? I'm wondering, if I buy Unity Pro now, will I eventually get these features without having to pay for upgrade?
     
  35. SeanPollman

    SeanPollman

    Joined:
    Jul 10, 2012
    Posts:
    55
    Nope, they will not be, Ive already asked and the only thing that will be in at 5 release is IL2CPP for iOS devices. this the reason Im pretty annoyed with UT right now. Who knows if they will be introduced in Unity5s lifespan, we were promised a new GUI in 3.5, and still waiting.
     
  36. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    Umm what? where did they say it like that? AFAIK 5.0 will not have any except webgl preview with IL2CPP and all others will come during 5.x lifetime.
     
  37. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    I'm pretty sure, or will clarify now, the only thing we are saying for sure is that IL2CPP will first be available via the WebGL early access add-on in Unity 5. We are not precluding it being anywhere else for the 5.x series, nor are we saying it will be available anywhere else within a specific time frame.

    So, WebGL first in Unity 5. Then almost definitely iOS coming next. Followed by other platforms as makes sense.
     
  38. SeanPollman

    SeanPollman

    Joined:
    Jul 10, 2012
    Posts:
    55
    Yes sorry that was my mistake. One of the core reasons this is frustrating for me, is that because we don't have current .Net capabilities we have to re-write an entire plugin on our end, because the security precautions we have in place to make sure we don't expose vulnerabilities on our users wont work with the current mono. So far its delayed deployment of that system two months now.
     
  39. pragmascript

    pragmascript

    Joined:
    Dec 31, 2010
    Posts:
    75
    I really don't see the point of delaying the mono upgrade till after the IL2CPP is "stable enough". A new Mono version is one of the most requested features and would be a good reason to upgrade to Unity 5.

    Look at this feedback thread with 1000+ votes:
    http://feedback.unity3d.com/suggestions/scripting-garbage-collection-sg

    It is from 2010!
    (and not a single developer commented on this feedback thread as of now)

    I understand that you cannot support the new Mono version on AOT platforms (for licence reasons) but that shouldn't stop you from upgrading to the new version on all other systems (e.g. windows desktop).

    PS. I don't want to sound all negative I think IL2CPP is an awesome idea and i love transpilers from a pure technical standpoint ;)
     
    Last edited: May 22, 2014
  40. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    Upgrading mono immediately could just present more problems, since they have two different versions of mono which may not entirely be compatible API wise.
     
  41. pragmascript

    pragmascript

    Joined:
    Dec 31, 2010
    Posts:
    75
    Which API are you referring to?
     
  42. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    The Mono API. But not only the API is a problem. C# itself would be updated and we could write code that is compilable with the newer Mono version, but not anymore with the older one. This would be an unacceptable situation.
     
  43. pragmascript

    pragmascript

    Joined:
    Dec 31, 2010
    Posts:
    75
    I don't see where the problem is. I do exactly that in visual studio all the time. You can target different versions of the .NET runtime in the solution settings.
    As long as the compiler generates IL that is compatible with the targeted runtime version no one cares about the specific compiler version used. For example the "var" keyword is only syntactic sugar and doesn't change the generated IL at all.
    Also we write code that is compatible with the desktop standalone but not compatible with the webplayer already.
     
  44. khan-amil

    khan-amil

    Joined:
    Mar 29, 2012
    Posts:
    137
    Wasn't the problem with iOs?
    i.e. , they can't upgrade Mono on this platform for licensing reasons, but once IL2CPP is on iOS, they're free to upgrade mono everywhere else.
     
  45. pragmascript

    pragmascript

    Joined:
    Dec 31, 2010
    Posts:
    75
    Yes, that's why I wrote

    IOS is a platform where they use AOT (ahead of time compilation).

    I just don't understand why they want to delay to support the newer mono versions on all other platforms according to:

     
  46. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
    C# remained back-compatible with the .NET 2 compiler up until .NET 4.0; that's why we can write .NET 3.5 code but still compile it through the .NET 2 compiler for Unity. But .NET 4.0 introduced new keywords into C# that will not compile through .NET 2 and generates incompatible IL. Namely the "dynamic" and "async" keywords, and some new ways of handling of generics.

    But, that said, I kind of agree that they could update anyway and just leave iOS incompatible. If they follow through with the plan to allow JIT on standalone but not iOS, that is going to result in almost the same amount of incompatible code. The "dynamic" keyword won't work in AOT Mono even if it does get updated to .NET 4.5, but it would with JIT Mono, so there will be incompatibility within the base language keywords anyway.
     
  47. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    +1


    While it is all nice and good you're trying to come up with a solution to the problem, a solution that is elegant and works well... this is 2014. We've been asking for you to do something for years. The current line of thought is Well, we've got this cool idea that we think might work, but we're not sure. It should be done sometime (but hey, no guarantees). Oh and look at this shiny new feature we're sure will distract you in 5.0.

    Given the difficulties you've faced in the past with integrating new functionality, do you have any plans like the following?

    If we il2cpp *hasn't* matured enough to upgrade mono (and GC) for the other platforms (e.g. desktop) in 6, 12, 18, 24, 30 and 36 months we will do x, y, z, a, b and c to rectify the issue. Even if this means we have to do q, r and/or s which we've been avoiding.
     
  48. Saxi

    Saxi

    Joined:
    Jun 28, 2013
    Posts:
    380
    More details on these browsers? They disabling all plugins, or just the Unity one? If just the Unity one, why?
     
  49. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
  50. Saxi

    Saxi

    Joined:
    Jun 28, 2013
    Posts:
    380
    Will IL2CPP do anything to fix the issue that Unity code even on iOS/Android can be reversed to clear text by a five year old? Rust sold over a million copies before it was even out of Alpha and because it uses Unity, you can read all the source code as if it was delivered with the product.
     
unityunity