![]() The modern compilers now take a managed language like c sharp convert it into a non managed language of c++ themselves for speed and then compile that into assembler. C++ was a non managed language that had to be compiled into assembler for a specific native platform but had the benefit of speed. It used to be that javascript or C sharp where interpreted managed languages which were slower but multiplatform. You don't have to replace the native plugins but just have it as an option so you have the best of both worlds. My point is as long as you give unity some code it can actually understand rather than only link to a native plugin that has already been compiled it can then be used on all platforms. Console manufactures are starting to do the same thing too. The reason google has blocked native plugins now is that HTML5 has got near to the point of matching its performance without the added security risks that go along with native. The overhead should only be in the order of about 5 % or so. My point is that unity with its upcoming newer compiler will be able to do the equivalent and on non html5 platforms will even compile it before hand for the specific platform so you don't need to even wait. The compiled version runs about 20 times faster. On my phone it starts off interpreting the water demo while it is compiling and I agree that it is unusable at that speed but after a few seconds after the compile it runs fine at 60 fps. Modern browsers no longer interpret html5 they instead recompile it and so can run it at near native speeds. On my nexus 5 that html5 webdemo starts off slow for a few seconds until it is compiled and then runs at 60 fps on a 2 year old phone. Perhaps you are not running the latest version of Android on your phone. I think you are underestimating modern compilers. I hope that clears up our decision to use a native plugin over a c# port. ![]() It might be possible to port our interface to javascript and include liquidfun.js in the html5 release. I will look into using the Emscripten javascript port with our Unity plugin. It would be possible with the browser plugin though only for security reasons, but not in html5. With regard to the web player you are correct, even if Unity provided web player plugins we would have to include a binary for each platform. Consoles are not supported and as far as I'm aware there are no plans to support them. We are also working on supporting Windows phone which should be released soon. We currently support both Windows and Mac on x86 and 圆4, ARMv7, ARMx86 and iOS 32 and 64 bit. ![]() It is a very basic example with and still doesn't give a useable frame-rate on my Note2, which can run over 6000 particles using the native plugin. The performance difference becomes apparent when I try the html5 testbed on the liquidfun site. For example the NEON SIMD assembly files would not work in a c# unity script. LiquidFun also uses some platform specific optimizations which would not be possible in a c# port. A physics engine is a perfect case where you should use a native c++ plugin in Unity to get maximum performance. I think the performance hit from using a c# port would be greater than it seems at first. ![]() Unity can do the same and will do all the converting for you but only if you give it c sharp or javascript that it can understand.Īlso the reason I say you should convert it to c sharp rather than javascript is apparently you get faster performance in unity html5 if you let it take c sharp code which it converts to c++ and then compiles back to javascript rather than writing the code directly in javascript yourself. HTML5 is compiled at runtime on the device that is using it so it will work with any processor. HTML5 is designed to run on any processor type for example arm or x86 or anything else. I don't think it is a security issue with html5 that prevents plugins it is a practicality. The way the plugin is at the moment also wouldn't work on consoles and also wouldn't be able to work in html5. For example there are some android devices that have x86 rather than arm chips in them so I am assuming it would error on them because it is always being natively compiled for a specific processor type. The issue with the way this plugin is at the moment in that it has separate dlls for different platforms holds it back. I am assuming there is a small performance hit from it not being natively compiled but the html 5 version on the liquid fun site works fine even on my android phone. You should do the equivalent in unity into c sharp from javascript. There is even an example of if running in html5 on the liquid fun site where they converted it from c++ to javascript. Physical liquid I think you really need to include a non natively compiled version of this as well as just the separate dlls for each platform. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |