Search Unity


While we have been developing Unity 3.4, we have ported the Unity runtime to the x86_64 architecture on Windows. You may have noticed that the Unity 3.4 editor allows «Windows 64-bit» as a new build option in the Standalone build. We have also ported the Unity Web Player to Windows 64-bit. This allows you to play Unity content in Microsoft Internet Explorer 64-bit or in 64-bit builds of Mozilla Firefox. Any Unity web content built with Unity 3.x should play in the 64-bit plugin. Content built with Unity 2.x will not work, as the 2.x runtime has not been ported to x86_64!

Since 64-bit browsers are not yet very widespread on Windows, the 64-bit web plugin has received limited testing coverage during our 3.4 beta. For that reason, we have decided to make this plugin available on an experimental basis for anyone who wishes to test or run Unity content in a 64-bit Windows browser. It is not yet available on our our main Web Player download page and the default JavaScript we supply for embedding Unity content will not link to it, so you have to manually download the installer. If 64-bit browsers become more common on Windows in the future, we will change this and release it as a fully supported product.

Without further ado, here it is!

Even though this is an unsupported product, please use the bug reporter which comes with Unity to report any issues you might have with the plugin!




Windows 64-bit plugin screenshot

Комментарии закрыты.

  1. Unity web player for LINUX please!! there is a Mac Os X version, so it uses OpenGL, then the portability to Linux should be easier.

  2. @Jonas Echterhoff I believe backwards compatibility is important (as long as it doesn’t hinder progression)
    However yes, 64-bit computing is not there yet. So good decision on still maintaining the deprecated APIs.

  3. baran salan4747

  4. Hi ,

    @ Jonas Echterhoff ,

    you mentioned that : «You may have noticed that the Unity 3.4 editor allows “Windows 64-bit” as a new build option in the Standalone build»
    so did you mean we can now export our Windows Stand Alone (.Exe) file with 2 options ???!!!

    both 32 bit and 64 bit ??? or is that feature only for the web Player??


  5. Symantec detects it as «Suspicious.Cloud». You guys should contact them about this false positive.

  6. @Treidge:

    Mainly compatibility with 64-bit browsers, yes. Also, the ability to access more the 4 GB of memory, but as long as the editor and all user browsers are not 64-bit, this generally won’t help you, because you don’t want to make content which runs out of memory everywhere else. But as memory gets larger and computers get faster, this will eventually become the common standard.

  7. Could anyone explain briefly what’s the benefits of 64-bit web player? Or it’s just for compatibility with 64-bit browsers for those who use it?

  8. @Richard:

    We have source code to all our dependencies at we are building most of the libraries ourselves. So none of this is out of our reach, it’s just a lot of work to be done. I actually don’t have an overview of which libraries are and which aren’t 64-bit compatible, but even for those which are, it is still a matter of updating our build process, sometimes finding out how to build them for stuff we haven’t updated in a while, etc. All that work x2 (Mac and Win) for over 20 external libraries adds up.

  9. Incidentally, while I understand that you probably can’t publicly name many of the non-64-bit packages you’re dependent on for business-relationship reasons, are there any open-source packages that are holding you up in the same way that maybe you *could* point at?

    Perhaps there are some devs in the community who want 64-bit and are willing to put the time into getting those packages to where you need them to be. Just a thought.

  10. @Jonas:

    I see — makes sense.

    Thanks very much for the info btw — one of the more frustrating aspects of Unity not supporting 64-bit is that there’s not been, to my knowledge, very much information about what the holdup is. It’s good to get a bit of concrete info, and to know that it’s not just that nobody inside UT thinks it’s worth doing :-)

  11. @Jozef:

    This is about the runtime as well, so if we want to remove the old code, we’d have to remove support for old OS versions for end users.

  12. Supporting two code paths is a wrong way, imho. Many Mac developers are iPhone developers too so they are using 10.6+.


  14. Exciting stuff, thanks!

  15. @Richard:

    yes, this does get us closer to both 64-bit Mac and 64-bit editor builds (which is part of the reason we did it — porting the runtime to 64-bit is a necessary subset of porting the editor). But both still have a lot of additional non-trivial work to be done first. The editor has much more code, and many more dependencies to third-party libraries then the runtime. And with Mac OS X, the biggest problem is that Apple has removed a whole lot of APIs from the 64-bit versions of their SDKs. Yes, these APIs have been deprecated for a while, but since we support running Unity as far back as Mac OS X 10.4, we are forced to still use many of these deprecated APIs. So we either have to support two code paths, or remove support for old OS versions to get 64-bit support on the Mac.

  16. Ah, interesting. I remember chatting to someone about why Unity wasn’t 64-bit already, and the suggestion was that it was being blocked by some dependencies on third-party code. If you’ve resolved those dependencies enough to get the runtime 64-bit on Windows, does that mean that a 64-bit Mac player isn’t going to be far behind?

    And then, perhaps, a 64-bit build of the Editor… ;-)