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

WebGL Roadmap

Discussion in 'Web' started by jonas-echterhoff, Jun 18, 2015.

Thread Status:
Not open for further replies.
  1. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Unity 5.0 shipped with a working preview of our WebGL technology in March this year. Since then, Google has disabled (by default) NPAPI support in their Chrome browser (meaning that the Unity Web Player will no longer work there) which is pushing a lot of Unity developers to try out WebGL as an alternative. Some people have already published games using Unity WebGL, but we have also heard from people running into issues porting their existing web player games over. It is important to understand that WebGL and the Web Player are - while targeting the same space - very different platforms with very different technical implementations, which means that not everything which is possible in the Web Player right now will be equally possible in WebGL. Also, it is important to understand that WebGL is a rather new technology with a fast moving ecosystem - so we expect that situation and the possibilities to be very different in maybe a year from now to what they are now.


    For this reason, I’d like to give an overview of things which are happening in the WebGL space, and our future plans around the technology.


    WebGL in Unity 5.1

    In Unity 5.1 our biggest focus was to fix bugs which would emerge from the initial WebGL release in Unity 5.0. Also, our IL2CPP team has been very busy fixing IL2CPP bugs over the past few month, with a huge number of those fixes and improvements going into 5.1. As WebGL uses IL2CPP as it’s scripting runtime, this also helps the WebGL platform a lot.


    While bug fixing was the biggest focus, there is also one new feature in Unity 5.1 of special interest to WebGL users: Crunch texture compression. Crunch texture compression allows compressing textures with JPEG-like compression ratios for transfer/storage, which decompress to GPU-friendly DXTn textures at runtime. This greatly helps reducing the distribution size of WebGL content, as textures are typically the assets with the heaviest size footprint.


    But let’s look beyond 5.1 and talk about our plans and visions for the WebGL platform in the future:


    “Preview” label

    Currently, a very common question we get is “When will you drop the ‘Preview’ label”? The answer right now is that we cannot tell. We will drop it when we think the platform is ready. The problem with that statement is that this is as much about our technology being ready for the platform, then about the platform ecosystem being ready for our technology. For this to work as well as we want it to, we need browser vendors to implement and improve some technologies we need. It does not make sense for us to drop the “Preview” label because we think that our stuff is ready, when the ecosystem is not - because to our users, what matters is that their content works, and not who is responsible for making it work. This means that readiness is not entirely in our hands in this case. That said, we are talking to all major browser vendors - and we do believe that they are doing a very good job to improve this technology and to get it where we want it to be. Read on for more details.

    Note that all the information in this post is based on our current plans and our current understanding of where the WebGL ecosystem is moving. All of this can change in the future. We are not committing to specific release dates for any of these features, and we may decide not to go ahead with some of these at all. If we mention Unity versions we expect features to show up in that is also subject to change.

    Memory issues


    One of the biggest issues we see people run into with Unity WebGL right now is browsers (especially Chrome) running out of memory on trying to run Unity WebGL content. There are separate issues here:


    • The need to allocate a continuous block of XXX MB of space for the WebGL content. This is the memory Unity will operate on. The size of this can be configured in the WebGL Player settings. This needs to be large enough to fit all the objects and assets Unity will have loaded at a specific point in time. You can use the Memory Profiler in Unity to debug how this space is being used. This needs to be a continuous block of memory in the browser’s heap. If the browser is low on memory, or it’s heap is fragmented, it may fail allocating such a block of memory.
    • Browsers needing too much memory to parse the JavaScript. The JavaScript code emitted by Unity for a WebGL player build is several orders of magnitude larger than other common uses of JavaScript, and JavaScript VMs may require a lot of memory to parse all this code. In particular, Chrome’s V8 sometimes runs into issues with this, causing it to crash, because it cannot allocate enough memory to parse the code. In Firefox, this is not as much of an issue, as Firefox uses asm.js to AOT compile the JavaScript, which has a smaller memory overhead.

    For a lot of use cases, this is currently the biggest show-stopping issue on WebGL, and it is not an easy one to fix. Right now, the best we can do on our side is to emit less code. We have been experimenting with this at our last HackWeek, where we had a project to see how far we can reduce the output size of our WebGL export. At the end of the week, we were able to build a simple Unity project to WebGL with a distribution size of 1.2 MB, by improving code stripping, improving compiler settings, and removing things we don’t need among other things. While this value is somewhat theoretical, as some of these improvements were made given assumptions we cannot make in general, we did learn a lot from this week, and I expect to see a lot of changes which benefit build output size to be rolled back into Unity starting with version 5.2. Also, we have build tools to visualize which code modules got included in the build, how much code was generated for those, and what caused them to be included. We plan to make these tools available in a future Unity release (5.3 at earliest), which should greatly help users to analyze and optimize their build output sizes. Reducing code output size also helps a lot with startup times, as it reduces the delay needed to parse the code.


    But, ultimately, we expect that these memory issues will be helped much more by advances in browser technology. All browsers are moving towards 64-bit builds, which lets them use larger address spaces. And, more importantly, Mozillla, Google and Microsoft are working on a new technology called WebAssembly which packages asm.js code into a bytecode format, which can then be very efficiently be compiled into native code. We are pretty excited about this, as this will greatly reduce load times, memory overhead and distribution size of WebGL content.


    Data Compression

    Very much related to the memory issues discussed above, distribution size is an issue and currently a source of confusion in Unity WebGL. Distribution size affects download times and memory usage. To keep download times reasonable, we want the data to by transferred in a compressed format. Currently, we rely on the gzip compression support built into the http protocol for that - because that allows the browser to handle decompression “for free” while downloading. Unfortunately, this is rather inconvenient to deal with, as it often requires manual setup on the server side to work correctly - plus gzip is far from efficient compared to more modern compression algorithms.


    In the future (currently scheduled for Unity 5.3), Unity will natively support compressing assets in it’s data files on all platforms, which will remove the need to rely on http compression for asset data in WebGL (and we will likely implement some custom compression handling for the code). This will make deploying WebGL content much easier, and as data will stay compressed in memory until it is used, this will also reduce asset memory usage (while in some of our tests actually speeding up asset load times, due to less memory bandwidth used).

    Performance

    We posted some benchmarks on WebGL performance last year, comparing browsers and native runtimes, which showed decent performance across the board in some areas, and larger gaps both between browser, and between WebGL and native in others. We want to make sure that those gaps will become as small as possible in the future. Most of the benchmarks were we have been seeing large gaps between native and WebGL are in areas which are heavily optimized to use SIMD and/or multithreading, neither of which are available on WebGL right now, but that will change:


    • SIMD.js: SIMD.js is a specification to add SIMD support to the JavaScript language. Mozilla, Google and Microsoft are all planning to support this. We will be able to use this to get the same SIMD performance improvements we get on other platforms right now on WebGL as well.

    • Shared Array Buffers: Shared Array Buffers will let WebWorkers (JavaScript’s equivalent to threads) share the same memory, which makes it possible to make existing multithreaded code compile to JavaScript. Mozilla has a working implementation of this spec, and they have successfully been running Unity WebGL content with multithreading enabled on this. They ran our benchmark project, with very good results on some of the benchmarks, resulting in several times higher scores when running multi-threaded. Google has also announced plans to add support for Shared Array Buffers

    Mobile support

    A very common question we get is when we plan to support mobiles with Unity WebGL. While we currently don’t do anything in order to prevent running content on mobiles (other than show a warning), in general, success rates are rather low (some high-end Android mobiles yield decent results, but most everyday end-user devices - not so much.). We don’t expect to see much change here before the above points on memory and performance see some significant improvements and performance of mobiles will have improved in general, so we cannot give any ETA on mobile support. We do believe that it will inevitably happen as technology progresses in the future, though.

    Build times

    Another common issue is that WebGL projects take very long to build. Mozilla is working on moving the complete emscripten compiler toolchain into native code (it is currently implemented in a mixture of languages), which we expect to improve build times significantly. In Unity 5.1 we have already seen emscripten updated to a version which moved JavaScript optimizations to native code improving build times compared to 5.0.


    Audio

    Currently, Unity WebGL uses a custom Audio implementation, based on the Web Audio, which is different from all other Unity build platforms, which use FMOD. This allows us to handle basic playback of supported audio formats with volumes and pitch. Any audio functionality which can be implemented on top of this is expected to work (and we fix bugs when it does not) - anything more advanced is not.

    We will not be able to change this until we have thread support in Unity WebGL (see the performance section), which might then allow us to compile the FMOD libraries to WebGL instead. That would get us close, but we’d also need APIs to set audio data from a worker, for which there is spec in Web Audio (“Audio Workers”), but that is not implemented in any browser yet. So, while we expect to have audio feature parity at some point in the future, there is no ETA on this, as it would rely on future technologies, and it may well take a while.


    Graphics

    WebGL is a JavaScript API based on OpenGL ES 2.0. This is somewhat limiting graphical capabilities compared to other platforms, because OpenGL ES 2.0 does not support a lot of features we use on other platforms. Also, Unity currently has some hard-coded decisions which tie graphics functionality to graphics APIs, which have been appropriate in the past when OpenGL ES 2.0 was considered a “mobile” graphics API, but with WebGL potentially running this code on higher end desktop GPUs, such assumptions may no longer hold up. This results in visual quality not being as good as it could be, especially when looking at shadows and the new standard shader. We have work in progress to fix this and make shader features configurable on a per-project base, instead of being hard-coded per graphics API.


    Also, at GDC 2015, we showed a prototype of Unity 5 running on WebGL 2.0 (which is based on OpenGL ES 3.0), which will take WebGL graphics capabilities up one step. Unity 5.2 is planned to ship with experimental WebGL 2.0 support, but we don’t expect browsers to actually support this API in release versions before the end of this year.

    Browser support

    Currently, Unity WebGL supports Chrome, Firefox and Safari. What is missing to get coverage of every major browser is support for Microsoft browsers. Current versions of Internet Explorer have WebGL support, but lack Web Audio support (so we cannot play any audio), and performance is not great, so while content may load, we do not currently officially support that.


    We expect this to change with the release of Microsoft Edge, the upcoming new default browser in Windows 10 to replace IE. Edge will support Web Audio, and supports asm.js resulting in great performance for Unity content.


    Video

    Unity’s MovieTexture class is not currently supported in WebGL. It would be possible to get the video part to work, but there are no current plans to do that, as our MovieTexture audio playback could not work with the current audio solution on WebGL, and more importantly, it is easy to simply use the browser’s html5 video functionality to integrate a much more full-featured video texture solution into Unity WebGL.

    Networking

    Neither System.IO.Sockets.* nor UnityEngine.Network.* work with WebGL. Nor will they ever. This is due to security restrictions on the platform, which disallow direct access to IP sockets on the platform. However, it is possible to use the WWW class, or to integrate with Web Sockets or WebRTC using JavaScript, or you can use our new built-in multiplayer functionality Unity 5.1, which supports WebGL via Web Sockets out of the box. Or you can use third-party libraries like Photon or SmartFoxServer, both of which support Unity WebGL using WebSockets.

    Threads

    As mentioned in the performance section, we plan to support multi-threading for our internal engine code using Shared Array Buffers, once browsers ship support for that. We hope to eventually extend this support to user code using System.Threading.* as well, but that is a more difficult problem to solve, as Shared Array Buffers will not provide some functionality required by our GC. We have some thoughts on how to work around that, and expect to have a working solution eventually at some point in the future, but that will likely be at a later point in time after we have added multithreading support for Unity Engine code internally.
     
  2. TechnicalArtist

    TechnicalArtist

    Joined:
    Jul 9, 2012
    Posts:
    736
    What about ios ?
     
  3. Schubkraft

    Schubkraft

    Unity Technologies

    Joined:
    Dec 3, 2012
    Posts:
    1,069
    See the section about Mobile Support.
     
  4. TechnicalArtist

    TechnicalArtist

    Joined:
    Jul 9, 2012
    Posts:
    736
    thanks for reply
     
  5. kenshin

    kenshin

    Joined:
    Apr 21, 2010
    Posts:
    940
  6. troy_halsey

    troy_halsey

    Joined:
    Oct 21, 2014
    Posts:
    68
    Really appreciate you laying this out for us. Many of us are banking a lot on WebGL and it's great to know Unity is taking it seriously and has a plan. Thank you @jonas echterhoff
     
  7. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Thanks. I think sharing this information was a bit overdue, but I was waiting for WebAssembly to be announced, as that is, IMO, what will make it all come together, and become truly great.
     
    jcarpay and NomadKing like this.
  8. VegetarianZombie

    VegetarianZombie

    Joined:
    Jul 16, 2013
    Posts:
    14
    That was some real interesting material. Thanks for sharing! It blows my mind how much work is necessary to get this feature off the ground.

    On a side note, with the open sourcing of Swift, has there been any discussions about the language having a place in the Unity ecosystem?
     
  9. Kronnect

    Kronnect

    Joined:
    Nov 16, 2014
    Posts:
    2,893
    Awesome news. You made my day.
     
  10. NomadKing

    NomadKing

    Joined:
    Feb 11, 2010
    Posts:
    1,461
    Thanks for the update.
     
  11. that-steve-guy

    that-steve-guy

    Joined:
    Apr 21, 2013
    Posts:
    15
    Glad to see the continued development....
    Great for the game developers...

    Yet this seems to fail to see 3D in a networked environment.
    I mean, 3D geometry and 2D images can be loaded in Unity on the fly - but scripts can't.
    Does that matter? - not so much for games, as the updating vs time playing ratio is fine.
    Other applications - however could use it.

    (heck this very website would be impossible without scripts loading in real time)
     
  12. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Great news, just wish we had all of the above now!

    It sounds like we should expect these technologies to roll out in the near future, will most of it arrive this year?
     
  13. aiab_animech

    aiab_animech

    Joined:
    Jul 4, 2012
    Posts:
    177
    Edit:
    Never mind, I missed part of your post!
     
  14. Mal_Duffin

    Mal_Duffin

    Joined:
    Jan 22, 2015
    Posts:
    71
    Many thanks for the update Jonas!
     
  15. Onsterion

    Onsterion

    Joined:
    Feb 21, 2014
    Posts:
    215
    Wonderful news!

    Thanks Jonas for take your time for create this post and explain us the future of WebGL in Unity.
     
  16. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    It's hard to tell. We are already very bad in predicting our own features, and it's much harder for features which depend on multiple third party vendors. If I were to make a rough guess, though, I'd say it is not unlikely that we'll see at least some browser/s ship support for WebGL 2.0, SIMD.js and Shared Array Buffers within 2015.
     
    NomadKing likes this.
  17. DudeGuy

    DudeGuy

    Joined:
    Jul 17, 2014
    Posts:
    19
    This is fantastic information Jonas. Much appreciated! I think you guys are doing a great job. I get asked a lot of questions about why some of these problems exist in our game (even though it's still in Preview mode). I think this may help to alleviate that a little bit. Looking forward to the future improvements. So much work to get this going.

    Thanks again!
     
  18. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    @jonas echterhoff

    I'm working on porting all my 'games' to WebGL http://arowx.com/test/ the problem is I then need to rebuild them all as WebGL imporoves and transfer them to my website, is there a way in Unity to batch build multiple projects?

    Also will the bytecode WebAssembly allow for a modular DLL style build so the interdependent modular elements of Unity need not be built into each and every game?
     
  19. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,815
  20. Schubkraft

    Schubkraft

    Unity Technologies

    Joined:
    Dec 3, 2012
    Posts:
    1,069
    There is no builtin batch building of projects but you can probably whip up a batch script that does just that for you.

    The WebAssembly just helps with decreasing the size of the emitted JS and faster loading so to speak (see the roadmap post). It won't magically make us better at stripping or being able to spin things out into reusable modules.
     
  21. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    @Schubkraft Found it WebAssembly's will have dynamic linking for CDN style libraries https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#dynamic-linking

    Cool and just under that wasm will have mmap, mapped memory, it has been used to great effect on mobile platforms to allow a game to use a set of larger than memory assets that can be dynamically pulled into memory when needed. Think level streaming and better memory footprints on mobile devices.
     
    Last edited: Jun 19, 2015
  22. De-Panther

    De-Panther

    Joined:
    Dec 27, 2009
    Posts:
    589
    Is there some explanation on what works and what doesn't work with the multiplayer and WebGL?
    Do we have to use match maker for it to work?
    Can we connect to a specific IP?
    Does a web client can "host" a game/room?

    And thanks for the Roadmap. Looking forward to work again on WebGL using Unity :)
     
  23. muzzydev

    muzzydev

    Joined:
    Oct 31, 2014
    Posts:
    7
    Great info - really appreciate the update!
     
  24. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    I don't know the answers, but I suggest you ask on our Multiplayer Networking forum: http://forum.unity3d.com/forums/multiplayer-networking.26/
     
    De-Panther likes this.
  25. ProtonOne

    ProtonOne

    Joined:
    Mar 8, 2008
    Posts:
    406
    This is great news! It's a pretty exciting time to be developing WebGL content with Unity. Reminds me of when the Unity Web Player was starting to gain traction, some things didn't work (like PlayerPrefs), but it continued to push forward until it was the best 3D experience on the web, I can see Unity WebGL heading down that same road.

    I really appreciate the hard work and technical challenges you guys at Unity are pioneering, the roadmap looks great!
     
    CreativeChris likes this.
  26. arumiat

    arumiat

    Joined:
    Apr 26, 2014
    Posts:
    321
    Will webGL be included with the Unity Cloud build at some stage?
    Thanks,
    T
     
    De-Panther likes this.
  27. Schubkraft

    Schubkraft

    Unity Technologies

    Joined:
    Dec 3, 2012
    Posts:
    1,069
    It is on the Roadmap for the cloud build team no set date for it yet.
     
  28. artzfx

    artzfx

    Joined:
    Apr 28, 2008
    Posts:
    572
    Great news, thanks for the roadmap Jonas.
     
  29. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    Thank you for the detailed explanation Jonas. Gives at least me more knowledge on what to look out for on the 'are we there yet' tracking front.
    It's great to see that you guys are still pushing the limits and the browser vendors there, pointing out problems that require serious usage of the technology to become truely visible.

    These efforts and your effort writting this up are very appreciated.
     
  30. sstephane

    sstephane

    Joined:
    Nov 5, 2009
    Posts:
    30
    @jonas echterhoff Thank you very much for taking the time to inform us on the status of Unity WebGL and share with us your future plans. It is very reassuring.

    I have one question about the web player build as I think one of the first motivations of Unity to early support WebGL was Google announcing the end of NPAPI based plugins support, meaning the end of Unity web player support on Chrome (soon completely).

    After reading your post, I have the confirmation that Firefox is still well ahead of Chrome with WebGL in terms of performance, stability, features (and coming ones). As a 3D web developer, I am a little bit worried about Mozilla doing the same as Google especially because of their advanced support. We already had to tell our users (thousands of them) to switch to Firefox to use our 3D web player based application as we could not offer them a WebGL port decent enough at this time.

    Do you have any information about Mozilla's plans you can share about NPAPI support? In any case, would you suggest me to do all I can, starting now to support WebGL to preempt Mozilla's possible move as soon as they would consider asm.js functonnality mature enough, knowing that my app does not even run at this time because of all the memory problems you mentioned and lack of multi-threading support.

    One last question, do you know if in the near/far future, memory allocation on the heap would be more flexible (on demand) like it is with the web player? Is it something browser vendors plan to allow in future releases?

    Thanks and keep up the good work!
     
  31. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    @dlerozeun : I have no information about Mozilla having specific plans for dropping NPAPI support. However, I believe that it is only a matter of time until they will. All of the browser vendors want to move away from plugins sooner or later, for security and other issues. Google was the first one to do so, I expect Microsoft to be the next with the release of the new MS Edge browser in Windows 10. So I do recommend moving your content to WebGL as soon as you can do so.

    As for the Unity heap being allocated flexibly - asm.js has added support for a growing heap some time ago, which we will probably support at some point. There are some performance implications we still have to research, and for best results, you would probably still want to set the initial heap size to be big enough to fit everything you might need (as now), so I am not sure this would be solving a real problem.
     
  32. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    But WebGL is a moving changing platform.

    Have you considered issuing 'specs' with each release? e.g. benchmarks, files sizes ect.

    For instance you could report on the build size and performance from Angry Bots and your WebGL benchmark suite in each browser.
     
    Creepy-Cat likes this.
  33. Elie-Charest

    Elie-Charest

    Joined:
    May 6, 2011
    Posts:
    14
    Hi Jonas,

    Sorry if I'm hijacking the thread, but I did not know where else to ask. I've been using your WebGL MovieTexture workaround (having to port a project to WebGL since Chrome no longer supports the Unity Web Player), and I got it working, except I have a small problem: the video is flipped horizontally (what's on the left appears on the right, and vice versa, with all text being backwards). This is in the test scene in the project I got from the Git repository. Is there a more recent version that fixes this, or if not do you know a workaround? I tried setting the horizontal texture scale to -1, but the video comes out only as horizontal lines. As a last resort I will try flipping my video files, but if you know of a way to fix this it would be much appreciated.

    Again, sorry if this is not the correct place to ask this, I tried to ask in one of the WebGL Video threads where you mentioned webglmovietexture, but they are all locked (I do not have enough privilege to post there). Thanks for all the great work, you guys rock!
     
  34. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,815
  35. Elie-Charest

    Elie-Charest

    Joined:
    May 6, 2011
    Posts:
    14
    Thanks Meltdown, I'll try there.
     
  36. yuliyF

    yuliyF

    Joined:
    Nov 15, 2012
    Posts:
    194
  37. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
  38. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    FWIW, the majority of those 37% of web player users still on XP are in China, where some of the largest Web Player games are being hosted, and where there are a lot of older systems around which still run XP, and most frequently use some non-recent version of IE. The Web Player will still work on those setups.

    If you look at the stats posted by @Arowx , they have XP listed at a much lower 3.3%. (This also shows how you should never trust a single source for your web user stats).

    That said, yes, for those users which are indeed on 32-bit OS and on Chrome, the situation is dire. This is unfortunate, but there is not much we can do about that at the moment. I think the best way to look at it is that with the web player, you would always lose a very large part of your potential audience due to people being unwilling to install the plugin. Even though you might lose the ability to target 32-bit Chrome users, your potential reach is still likely higher with WebGL then it was with the Web Player in the past.
     
    metameta_games likes this.
  39. jonkuze

    jonkuze

    Joined:
    Aug 19, 2012
    Posts:
    1,709
    As much as i'm happy about the transition to WebGL, Google has truly made this a painful experience for choosing to no longer support NPAPI! I wonder how long it will take for everyone to catch up, as in the market share for 64-bit OS shifting to something like 80% that will help us tremendously. Currently I'm getting close to publishing a small WebGL game with a browser-game publisher who has global reach. I'm going in blind, with no idea what the outcome is going to be with how many people can actually load the WebGL version despite my major efforts to optimize my game as much as possible. :confused:
     
    Last edited: Jul 8, 2015
  40. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    NomadKing, Dantus, ProtonOne and 2 others like this.
  41. jonkuze

    jonkuze

    Joined:
    Aug 19, 2012
    Posts:
    1,709
    Thanks Jonas! Also, geez I just noticed that @yuliyF is pointing out that Chrome is killing Web Player sooner than they orginally said they would. Here it states September with Update 45! https://www.chromium.org/developers/npapi-deprecation but now in https://www.chromium.org/developers/calendar it states this week! :eek: crazy!! Count down to the end of Web Player's life on Chrome only in 2 days...

    Edit: Just read through the Road Map! Pretty Awesome if they can achieve all that they list! I'm sure Chrome will be right behind them on this. Curious if Chrome plans to publish something similar, although I get the impression Chrome doesn't care nearly as much about game technology in the browser as Mozilla does (i've seen more news updates from Mozilla's end than Chrome, actually don't recall ever seeing anything from Chrome on the topic of games technology).
     
    Last edited: Jul 8, 2015
  42. kulesz

    kulesz

    Joined:
    Jul 1, 2012
    Posts:
    138
    I wonder whether they'll stick to the date (September 2015) or stop their support at version 45 (that's just coming much earlier). I guess everything should be clear by tomorrow?
     
  43. jonkuze

    jonkuze

    Joined:
    Aug 19, 2012
    Posts:
    1,709
    I actually don't care anymore... lol! it's only 2 months away anyway so might as well put an end to it now, no sense in a slow painful death lol. Just get it over with already. One less thing for me to worry about and have to support. As I have been spending time worrying about uploading Web Player Builds of my current Project but I think i'm just going to go 100% WebGL. It's time to move on...
     
    Meltdown likes this.
  44. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    The development calendar you linked lists branch points, not release dates!
     
  45. jonkuze

    jonkuze

    Joined:
    Aug 19, 2012
    Posts:
    1,709
    Ah I see... Ops! Ah well... they might as well kill it tomorrow lol! I'm done with NPAPI anyway bring on WebGL!
     
  46. kulesz

    kulesz

    Joined:
    Jul 1, 2012
    Posts:
    138
    You would, if your business and living would depend on it :)
     
  47. yuliyF

    yuliyF

    Joined:
    Nov 15, 2012
    Posts:
    194
    today is friday, will be webGL update -?
     
  48. jonkuze

    jonkuze

    Joined:
    Aug 19, 2012
    Posts:
    1,709
    O I have already been down that road... one of my first successful browser-based titles was developed with Adobe Director on Adobe Shockwave! It's been blocked for sometime and I lost alot due to it, I earned a living from it for about 1-2 years. Not much I could do, just needed to move on to the next best thing. It's the nature of our industry, just need to keep up, dust yourself off, never give up, and keep pushing foward.
     
  49. skeleton-king

    skeleton-king

    Joined:
    Nov 10, 2014
    Posts:
    63
    I hope data compression gets implemented. Major issue with webgl right now is its build size. For a browser game we cant expect to go beyond 50mb which is hard to achieve now wihtout compression.
     
  50. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    WebGL already supports gzip compression over http right now (look at the "Compressed" folder in release builds), so I would not expect this to make a big difference in distribution size (though you will probably be able to choose different compression formats, letting you choose a tradeoff between loading speed and size which will let you get a better size then now). The big change is that compression will be on the level of Unity asset serialization, and not on the level of http transfers, so you don't only benefit in distribution size, but also in memory usage.
     
Thread Status:
Not open for further replies.