Mozilla Games Technology Roadmap
blog.mozilla.org
blog.mozilla.org
Either that or please suggest a viable workaround
There's also the option of my phone connecting to my home pc while it uses 4G (while the PC uses the land connection).
But yeah, "SSL-only" kinda breaks the end-to-end principle since we have no mechanism to assign SSL certs to endpoints on demand. So it seems flawed on a conceptual level.
https://pfigue.github.io/blog/2013/12/06/configuring-dnsmasq... (but without --server)
and this
https://stackoverflow.com/questions/28204678/dns-service-to-... (specifically, the "synth-domain" parameter, maybe limiting it to LAN ip addresses)
I haven't tried it.
All of this, of course, only if there are some desired HTTPS-only features in the browser.
I wonder why local storage even is a thing.
It doesn't interface nicely with facilities provided by host OS.
Providing file IO to a fenced-off, per-origin part of the filesystem would allow people to roll their own data serialization and allow users and desktop applications to drop in/pull out files as they desire.
Seems to me that one nice feature for HTML gaming is the ability to deploy a paid version to Steam/GOG/etc..
[1] https://developer.mozilla.org/en-US/Apps/Quickstart/Build/In... [2] There's none for Webkit/Chromium either, as nwjs/atom-shell are third-party projects. [3] https://developer.mozilla.org/de/Marketplace/Options/Open_we... [4] https://github.com/mozilla/apk-factory-service
Also, is there really that much demand for games in the browser? If you'd like to see a few thousand bad ones, go to "newgrounds.com".
My wife prefers Chrome to Firefox purely because Flash tends to stutter more on Firefox, and she plays a lot of Facebook games.
One of the few things Mozilla CANNOT do is to make Flash run better. Flash is closed source, proprietary software, owned by Adobe. Google did their own implementation (of at least the browser interface + sandbox), I supposed after signing plenty of NDA and handing money over. That's not something Mozilla can (or should) do as an open source project.
Whatever plans you will go looking for at Mozilla, you'll never find "improve Flash" in one of them, even as an option. It just isn't possible. It's like asking Mozilla to make Office run better.
They've offered Shumway as an interdependent re-implementation, but I'm guessing it has tons of compatibility issues as Flash isn't a standard.
You're probably better off just uninstalling Flash in Firefox, to be honest.
We work with Adobe to identify and fix Flash crashes collected by Firefox's crash reporter. We've made NPAPI plugin initialization asynchronous to avoid Flash blocking page load. We're also prototyping a new plugin sandbox to replace Adobe's Flash sandbox (which is based on an outdated fork of the Chromium sandbox).
Here is more information about some of the plugin work:
Therefore, either the Flash people are deliberately detecting that it's being run in Firefox and slowing it down, or Firefox is doing _something_ which has made it stutter intermittently on every PC that my wife plays Facebook games on.
Would you care to hazard a guess as to what might be going on?
Firefox doesn't. It also doesn't update flash for you, you need to do that.
That's the difference.
But that is just bad habit of programmers, not the issue with the technology per se.
4 years ago I was very bullish on HTML5. Flash was dying, HTML5 was the future! It was right around the corner! I think a lot of people agreed with me.
4 years later - what has changed? Decent webGL support but still driven by a terribly slow javascript runtime. ASM.js gets us halfway there but it's brittle and does't even run in Chrome so it's basically worthless for anything that isn't a tech demo. The audio API is also still very limited.
We've been trying to port our Unity mobile app to webGL for 6 months now and it's been nothing but pain. In hindsight, it was a mistake. I was bullish on HTML5 back in 2011 and I was bullish on webGL in 2014. I was wrong, again.
So, I'd like to have faith in these efforts, but as they say, "Fool me once, shame on you. Fool me twice, shame on me."
First off, HTML5 has come a long way – there are still areas that need work, but generally I've seen lots of great HTML5 games and the field has improved remarkably in the past 4 years.
WebGL support is now cross-browser. The JavaScript runtime is not terribly slow, and I don't know if you're a bit confused about ASM.js – it does run in Chrome, and pretty well too. However, it's likely to be displaced by WebAssembly going forward, if I understand correctly, and that will be cross-platform and cross-browser.
It'll take a little while, but we're on the way there! Unity's HTML5 examples are pretty good – http://beta.unity3d.com/jonas/AngryBots/ for example looks great and runs well.
HTML5 has come a long way, but I'm talking specifically about non-trivial games. For that, it's quite difficult to use it in a "we are going to make money with this!" way. I have seen some success with people writing their whole game from scratch to work within the very limited scope of HTML5, but most of the time those games are still pretty simple. Even so, I will concede that maybe this statement is geared more towards people trying to do cross platform stuff.
> ASM.js – it does run in Chrome
ASM.js runs in Chrome but it's not accelerated like it is in Firefox, that's what I mean. I was not speaking literally.
> http://beta.unity3d.com/jonas/AngryBots/ for example looks great and runs well.
That's a demo. It does not demonstrate the problems that real developers with real games and real codebases are having with webGL. For example, it does't do any network communication with a server.
And, this game is tiny. They have 14.5 mb of assets and 4 mb of javascript.
Our game (it's a Slot Machine so it's not like it's super complex) has 23 mb of data and 16 mb of javascript. This is much more realistic. You can't do a whole lot with only 4 mb of javascript.
I know they've been working on WebGL 2 (OpenGL ES 3.0-based) for a while, but if it doesn't ship within a year, they might as well scrap it in favor of a Vulkan-based API.
I agree, so in the meantime what do we do?
As the CTO of a mobile/web game startup (using Unity), I'm really struggling on what to do here. We have been trying to launch on Facebook Canvas since late 2014 and so far the finish line isn't even in sight.