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.
I wonder if that influenced Unity's decision to not use virtual function calls into MonoBehaviours?
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.
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.
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.
Yep, thats pretty much what i'm hoping for, though fully understand it will take time before you get to that stage.
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?
#1 (the bottom one)
Okay cool, thx.
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
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.
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).
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.
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?
That was answered several times, namely that the editor stays the way it is. (With a newer Mono, eventually.)
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?
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.
Well sorry... many posts to read Thanks anyways
Totally agree here.
So much effort and problems to keep C# instead removing it completely and going C++ all the way.
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?
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.
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?
This doesn't affect anything with scenarios with native plugins like chipmunk.
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?
(from the blogpost)
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?
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?
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.
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.
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#.
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.
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)
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).
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
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?
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.
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.
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.
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.
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:
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
Upgrading mono immediately could just present more problems, since they have two different versions of mono which may not entirely be compatible API wise.
Which API are you referring to?
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.
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.
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.
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:
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.
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.
More details on these browsers? They disabling all plugins, or just the Unity one? If just the Unity one, why?
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.