5 ms·
Nice to see this: > HTML5 platform + WebGL is ready to use -- run your game in a compatible browser with a single click!
by azakai 12y ago
Nice to see this:
> HTML5 platform + WebGL is ready to use -- run your game in a compatible browser with a single click!
- jgrowl 12y ago(WINDOWS ONLY) :(
- azakai 12y agoI assume that's a temporary limitation, they have lots of developers on OS X.
- melling 12y agoYes, they state that in the article. "Windows is currently required for HTML5 support. We’re working on Mac for an upcoming release."
- vertex-four 12y agoThat's just building that is Windows-only, obviously the apps will work on any reasonably modern browser. And OSX support should likely come as soon as they can package the tools properly.
- rl3 12y agoMore detail on browser limitations would be nice. I know the article states you can ship builds in 32-bit browsers, but are there any significant limitations involved? This would be problematic since, for example, Chrome 64-bit isn't yet the default release build. I really wish there was more comprehensive documentation relating to UE4's limitations in a WebGL context. For example, lighting, shading, post-process effects, anti-aliasing, how they all behave relative to a full-featured desktop environment. The same thing for mobile compile targets wouldn't be a bad idea, either. Also, it seems some otherwise popular third party plugins aren't supported in UE4 WebGL projects: https://forums.coherent-labs.com/index.php?topic=691.0 https://forums.coherent-labs.com/index.php?topic=691.0 I understand Coherent's reasoning, but I imagine developers who built their UE4 projects with Coherent UI aren't very happy that their prospects of easily compiling to WebGL are non-existent due to the total headache involved. Plus, webkit.js for UE4 would be really cool, and that's essentially what CUI running in a UE4 web-exported context would be. Despite all this I'm really happy for this release, and ultimately it's a huge step in the right direction.
- desdiv 12y agoThis is problematic since, for example, Chrome 64-bit isn't yet the default release build. Surprisingly enough, there isn't even an official supported build of Firefox 64-bit for Windows. Coupled with the Chrome issue you mentioned, I'll bet that at least 80% of users out there aren't using a 64-bit browser.
- TazeTSchnitzel 12y agoThere used to be a 64-bit Firefox, I think it was short-sighted of Mozilla to drop it. Oh well.
- Fr0styMatt4 12y agoThis is insane in 2015. I understand the difficulties of porting, but at the same time, I've had a 64-bit CPU since 2009 and I was late to the party :)
- smooc 12y agoDid you check the article? In the pictures they actually launch 32bit firefox.
- rl3 12y agoDespite looking at that very section, I somehow totally missed that. Edited my original post accordingly, thanks!
- TazeTSchnitzel 12y ago> I know the article states you can ship builds in 32-bit browsers, but are there any significant limitations involved There shouldn't be any. asm.js is actually a 32-bit target (probably by sheer coincidence since JS only has 32-bit integers).
- rl3 12y agoThis is from October 2014, so some of it may be outdated: https://forums.unrealengine.com/showthread.php?48463-HTML5-Capabilites https://forums.unrealengine.com/showthread.php?48463-HTML5-C... >5. My Game doesn't run. That section outlines the memory concerns that I failed to articulate earlier. Assuming it's still true, then it seems half a gigabyte is the upper bound. This would then preclude precomputed lighting in most cases, but it seems like a moot point since you'd have to send the (baked) textures over the network anyways. --- As an aside to my earlier questions about rendering (past the edit window on my other post): >HTML5 builds uses the Mobile OpenGL ES 2 rendering code path and use WebGL internally and should be at feature parity with Android/IOS as a thumb rule. Given that, the following seems to give a good idea of what the WebGL compile target is capable of as far as rendering features: https://docs.unrealengine.com/latest/INT/Platforms/Mobile/index.html https://docs.unrealengine.com/latest/INT/Platforms/Mobile/in... I'd say there still remains some ambiguity in certain areas, though. While mobile and WebGL compile targets both share the OpenGL ES 2.0 limitation, mobile seems far more performance-bound and that appears to influence its feature set accordingly.
- daredevildave 12y agoDo they mention output file size?
- greggman 12y agoIt's not nearly that easy. It would be good to know what the minimum size is. If all you want to do is put a cube on the screen how large is the JavaScript blob you have to download? Then, most games have tens or hundreds of megs of data. Does Unreal do anything to help this? An ideal HTML5/WebGL game engine would have many of the features of flash letting the game start with a minimal amount of data and downloading the rest in the background and/or on demand. I know of no WebGL game engine that handles that in any graceful and developer friendly way though I'm sure it will come at some point. On top of that you need to deal with where the user is coming from. Are they on a phone or tablet with only touch controls? A slow desktop? A fast desktop? Do you handle both mouse and touchpad? I've seen almost no games handle these issues. Almost all assume you're on a desktop with a mouse which might be true for gamers but is not true for most people browsing the web (mobile or desktop). For mobile you could check and tell them to download the app. Does Unreal deal with any of these issues in a dev and user friendly way? Until then though most Unreal->WebGL or Unity->WebGL apps will probably have relatively poor user experiences.