Microsoft has joined Khronos, WebGL working group
twitter.com
twitter.com
Also, for old monopolist Microsoft, standards were a bane because they meant smaller players could interoperate with its software, and even sometimes influence its future via standards committees. For new underdog-in-certain-markets Microsoft, standards are a blessing because it means they can interoperate with larger players' software, and even sometimes influence its future via standards committees. I'm not sure how much that's taken hold culturally within MS, though. (And, of course, there are many places they're still not the underdog.)
If your application is inherently networked, it works just fine in the browser.
With regards to game distribution, I don't see any particular advantage that a browser has over something like Steam. You don't need to download multiple gigabytes either. You could design a game to stream levels/assets/etc on-demand. In any case, even with webGL, a game would need to do that.
It is convenient. What is it not understandable about that?
I already excluded this part from my criticism. Please read my original comment.
>You can't say the same for Steam.
So, the solution to that is to create something like Steam, but better. Choosing an inferior technology is the opposite of a solution.
I predict that advertisers are going to overuse webGL just like flash. We're going to see webGL blockers crop up the minute it gets any kind of traction. Certainly, I am not going to subject my machine to another malware vector.
Absolutely not; the sandbox of Javascript apps is entirely within the browser. The CPU architecture may theoretically prevent a userspace app from breaking into ring 0, but that's not the interesting thing; you're trying to prevent random apps from gaining access to all the tasty data in userland.
"Please do not download and run random executables" is a lesson that security people have been trying to get across for a while. Running a native game executable involves trusting it not to be malware. Running a webgl or HTML5 game does not.
(The sandboxing of webgl may be dodgy, which is a weakness here.)
I don't know why you felt compelled to state a categorical denial when the facts dispute it. Please read up on how security tokens work in Windows, for e.g.
http://msdn.microsoft.com/en-us/library/bb625957.aspx
> Running a native game executable involves trusting it not to be malware. Running a webgl or HTML5 game does not.
There is no difference between those two executions in modern operating systems that implement mandatory access control.
Also, I do think the author is joking with regards to it being 'the best tested 3D API'. The author backs up this absurd claim with some 'thousands of tests' comment. Hello? Have they never visited shadertoy? Even trivial shaders cause webGL to crash because of the poor implementation quality. I refuse to believe that a person who has had any experience shipping OpenGL ES on multiple platforms could make such a statement.
- potential future GUI solution to end the sad HTML5-only lock of the web;
- useful for quick dirty prototypes/samples for full OpenGL tutorials;
- generating HN karma: just find any old OpenGL sample (quality doesn't matter), convert it to WebGL, post on HN (make sure to add 'WebGL' and 'JavaScript' to title) - ka-ching!
On the other hand, the use of Direct3D is a competitive advantage for them. It made ports easier with the XBox 360 and it probably still makes them easier for the XBox One.
You mean MS doesn't want it. MS is not everybody though. Xbox is one of the ways they can keep DirectX around in the face of potential competition as you said yourself:
> Direct3D is a competitive advantage for them
Though I'd call it an anti-competitive advantage.
As far as I'm aware, devs aren't too keen on it. No other maor consoles are using it anyway, so the X-platform argument doesn't really apply.
1. http://www.amd.com/en-us/innovations/software-technologies/m...
2. https://developer.apple.com/library/prerelease/ios/documenta...
Also, Mantle was supposed to be open. Did AMD open it already?
Because of current market lock-in on DirectX. OpenGL isn't ideal, but it's not much behind. MS however doesn't want it to become better and is scared of more competition from cross platform APIs. Not sure why though. These days lock-in with API is a very dumb method to compete.
I think Valve has a good potential to push things forward.
Regardless of FOSS myths, no console has proper OpenGL[0] support.
[0] Yes, not even the PS3.
Valve will have to do lots of work just to try to pull off the same quality of developer support console vendors offer.
Let them. Improving developers' tools around OpenGL was one of their key plans in this effort. So far they look serious about it.
But on the console, the target is constant, and every Xbox One or every Playstation 4 is identical to every other of the same console on the market. The overhead of the OpenGL/DirectX driver reduces performance, and unlike in the PC market it's no longer solving a problem -- you can very easily support two to three consoles without resorting to abstraction layers, and new consoles only come out sometime between five and ten years, so you don't have to do a lot of churn to keep up with hardware revisions.
Valve isn't shipping consoles, they're shipping living room PCs -- with all the diversity of hardware that implies. Some Steam Boxes will use Nvidia, others Intel or ATI. Games designed to run on Steam Boxes need to support all of those. They need OpenGL. But current consoles don't, and no amount of OpenGL stumping by Valve will change that, because OpenGL solves a problem the consoles have never had.
That's exactly what should change. Such situation can exist only because of lack of competition. With increased competition the overhead of writing bare metal code to support many targets will become prohibitive on consoles as well, and console makers will be forced to support portable higher level APIs. Squeezing performance by being closer to bare hardware was more reasonable in the past, when it was too weak and extra abstraction introduced too much performance penalty. Modern day hardware should be already better in this regard. And modern OpenGL isn't introducing much overhead if used properly.
> OpenGL solves a problem the consoles have never had.
They always had that problem, except there were too few of them and the problem didn't become criticial. Increased competition will blow that problem into different proportions. Supporting 2 console APIs is possible. Supporting 10 is insane and developers should demand a portable layer in such situation.
Why? For people who don't want to deal with the Xbox One/Playstation 4 monocultures, there's PC gaming. It already exists. The people who choose consoles over PC gaming choose it because it's more convenient. And that convenience derives in large part from the monoculture (or duoculture, I guess). Low-overhead bare metal programming is what enables the relatively long life of most consoles compared to PC gaming, because developers have time to learn how to get the absolute best performance out of a particular hardware configuration. It costs less money up-front in hardware costs, and it's a lot less work to figure out if a game will work on your system or not (almost no work, actually).
Because dealing with many APIs is an extra effort and proprietary APIs make games harder to port to other platforms. Of course those who have unlimited resources are free to write games even in assembly for each platform, but most don't have such resources.
> And that convenience derives in large part from the monoculture
Convenience of users has nothing to do with monoculture. It has something to do with form factor and design of hardware and software interfaces. Monoculture is just a sick method to lock developers into one platform. Convenience of developers on the other hand should not be based on poor competition. That's a dangerous convenience which leads to stagnation.
> Low-overhead bare metal programming is what enables the relatively long life of most consoles compared to PC gaming
Which is a double sided issue. Longer update cycle makes development simpler but it also limits creativity by artificial technical limits. The update cycle of consoles can be reasonably more frequent.
Game engine middleware. No sane people should be using 3D API directly anyway, unless they are writing their own engine or learning 3D programming.
If as a developer I could have one codebase and target all three platforms it would be pretty compelling.
I mean, I know why - it is because the entire console model is license deals, app store cuts, and exclusives. If you could write your games and seamlessly run them everywhere, console manufacturers lose their primary pitch to consumers. Especially since this console generation isn't amazing value hardware wise, you can build a computer as powerful as either for the same price as either.
And peripherals are an awful argument, because they are all wifi / bluetooth / usb based, nothing stops these companies from selling their accessories like the Move, Kinect, Wiimote, etc as pc peripherals with open APIs besides their complacency.
Valve is just entering consoles scene. It's too early to call that pressure, but they at least plan to disrupt it. Time will tell.
> it is because the entire console model is license deals, app store cuts, and exclusives.
Yes, that's why this sick approach needs some serious disruption. Linux gaming looks like one.
> if you could write your games and seamlessly run them everywhere, console manufacturers lose their primary pitch to consumers.
Exclusivity is a weird pitch. Real pitch of consoles should be in ease of access, usability and user friendliness.
> you can build a computer as powerful as either for the same price as either.
That's exactly what consoles should be about - plug and play. No building for those who don't want it. All of that doesn't preclude using cross platform technologies. Let console makers compete on hardware (Asus, Dell whoever) and not on locking developers into their walled garden proprietary OS and APIs.
Microsoft needed to join to have an opinion at all.
Most people consider that a good thing, considering that both of these technologies were abominations that required proprietary plugins full of security holes, that didn't even run everywhere you needed them.
I'll give you that they were buggy, but Flash enabled a LOT of cool stuff to be delivered on the web that HTML still can't do. Go visit Newgrounds or Kongregate and see what people have been doing, basically unchanged, since the late 90s.
I'm not sad that it's gone, but it was pretty great at what it did.
While Apple refusing to embed Flash on iOS is what killed it, truth be told at that time Adobe wasn't capable of delivering a mobile version that worked well, as they lacked the resources for it, just how they lack the resources to deliver a supported and polished Linux / NPAPI version, which was dropped. The version that was bundled with Android, with all due respect, was horrible. Flash only worked well due to the Windows monopoly, but the approach eventually broke down due to mobile devices.
HTML5 may not be so evolved, but at least it works on my Android in both Chrome and Firefox, it works on my MacBook, it works on my Ubuntu Linux, it works on my Windows Phone that I keep around as a paper holder and it works on my iPad. And if portability and instant updates and everything else that makes the browser great are not that important, then you're better off going native.
If Adobe had open-sourced the Flash client (but not the authoring tools) I like to think we would be in a different space technically. Certainly I hope we wouldn't have spent the last 6 years redesigning Flash by committee. Possibly licensing concerns around codecs and other things would have blocked it anyway, but one can dream.
I just think Flash deserves respect for filling in the "online multimedia" space so well while others played catch-up. Well, they caught up.
I dislike HTML5 for this reason. In the heyday of Flash you could sidestep most of the bloat of the web with a click-to-play plugin setting or by not installing the extension at all, and 99% of the sites that relied on Flash completely for navigation etc. weren't worth browsing in the first place. Now that many of the capabilities of Flash are built into the browser, you don't really have a way to avoid superfluous animations and awkward nonstandard interfaces and whatnot. Every time I have to use a Wikia wiki, my computer and I each shed a single minimalist tear.
The main reason ANGLE is preferred is that in general, on Windows GL drivers are dramatically inferior to D3D drivers. They are slower, less stable, and sometimes omit key features. D3D historically has a much better story for preventing shaders from hanging/crashing video drivers, and for recovering from failures that do occur (lost surfaces, driver TDR, etc) - something that GL has now in modern implementations, but didn't have consistently when WebGL was introduced.
Between the more widespread availability of good D3D drivers and the stability advantages, I suspect you might not see ANGLE vanish anytime soon - despite the fact that GL drivers for Windows keep improving.