5 ms·

WebGL isn't trying to be competitive with full blown game engines, is it? For one, game engines normally don't use OpenGL unless they have to. The GL drivers o

WebGL isn't trying to be competitive with full blown game engines, is it? For one, game engines normally don't use OpenGL unless they have to. The GL drivers on PC tend to be very weak. High end games target Direct3D on Windows/Xbox and these days are moving to Vulkan/Metal, even on mobile. On Windows the GL driver situation is so bad that Chrome translates GL to Direct3D. This obviously will impose some overhead and complicate the driver bug situation still further. Even when games do target GL they tend to exploit lots of vendor specific extensions and be tested against very specific graphics card/driver combos to enable them to workaround bugs and performance cliffs. Does WebGL even expose driver specific extensions? I don't think it does. So you are not going to be competing with native apps on the web anytime soon in this area (as with all other areas...)

skocznymroczny 9y ago
The recently released Doom game is using OpenGL (and Vulkan).
- zanny 9y ago
  id has always made opengl engines. They get to deal with endless driver breakage. When Rage came out I believe AMD cards didn't work at all for over a week.
  - slavik81 9y ago
    Bioshock was a DirectX game and I recall that shadows were broken on AMD at launch. There are some OpenGL-specific problems with driver breakage, but AMD would be in much better shape today if that's all it was. If you read through the patch notes for your video card drivers, you'll probably notice that every major game release gets special support right in the driver. NVIDIA has three advantages: 1. Most PC gamers have NVIDIA cards, so developers test primarily against NVIDIA cards. 2. NVIDIA has a boatload of driver developers to hack game-specific fixes and improvements right into their driver. They work around game bugs, rewrite slow shaders, and other stuff like that. I assume that's part of why the graphics driver is now well over a hundred megabytes. 3. NVIDIA sends developers to major game studios to optimize and add graphical effects to their games. For instance, volumetric lighting in Fallout 4 was added by an NVIDIA employee. I think AMD does much of the same, but they just don't have the money to do it to the same extent. That means more breakage and slower fixes.
iainmerrick 9y ago
WebGL isn't trying to be competitive with full blown game engines, is it? Sure it is! Not right now maybe, but the web standards people working on it would love to be a viable platform for AAA games. Every so often they tout a new WebGL port of a well-known game as the harbinger of things to come.
- bflesch 9y ago
  I'd love to build webgl multiplayer games. I hope to get the chance working on these things in the future.
- peoplewindow 9y ago
  Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? I think they're more concerned with the politics of it than the technical requirements of that userset. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments.
  - iainmerrick 9y ago
    (I'm mostly playing devil's advocate here, I don't actually think HTML will be suitable for high-end games in the near future. But I think there are decent arguments to be made...) Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? Mobile. They picked OpenGL ES 2.0 for WebGL because it had comprehensively won on mobile. Apple went with ES 2.0 and Android followed. It's taking a long time for the mobile industry to migrate to ES 3 (which would allow WebGL 2) but ES 2 has been a decent stable baseline for a good few years now. That's quite unusual, and very helpful, given how fast-moving everything in tech is. [Edit to add: ES 2 is based on GL 3, which was the first version to add programmable shaders. That was a huge API change, and an admission that the D3D approach was better. It's barely 10 years old. So any "GL is unpopular" arguments based on the old fixed-function pipeline are a red herring, I think.] Mobile was and is more important than either desktops or consoles, because the mobile market is huge and growing, while desktops and console are at best stable. Google came up with a clever technical solution (the ANGLE library) to emulate ES 2.0 on top of Direct3D, so that sidesteps the technical problems of OpenGL on Windows. Now, for AAA games, desktops and consoles are obviously far more important. I think there are two responses to that: First, a bet that mobile will gradually catch up and become equally important. There are a lot of factors involved, but on raw technical terms it's not such a bad bet. Mobile hardware iterates very fast, and some mobile CPUs are getting very competitive with desktops (recent iPads and iPhones especially). Sustained performance is an issue, as mobile devices have much stricter thermal limits; but you can put the same mobile SoC in a bigger box, like the TV set-top boxes that Google, Apple, Amazon and others are experimenting with. Second, there's no reason WebGL 3 couldn't be based on Vulkan. WebGL 2 hasn't even been fully adopted yet, so it would obviously take a number of years to make that happen. Maybe desktops and consoles will have moved on to something newer and better by then, but maybe they won't. The big question is whether mobile+web is catching up on desktop+console, or if it'll always be a generation or two behind. I think you'd have to be pretty brave to bet against them ever catching up. I think they're more concerned with the politics of it than the technical requirements of that userset. I'm sure politics plays into it, but for WebGL specifically, it must have been a pretty easy technical decision. Do you pick the 3D standard used on Windows, or do you pick the lower-end one used by iOS and Android (and can be made to work on Windows)? You could ask why GL rather than D3D won on mobile in the first place. For that you have to look at Microsoft and ask why Windows Mobile failed (in all its different versions). I don't think you can blame that entirely on politics. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments. That's a good point. From a web standards standpoint, it's a very tough conflict to resolve. I think the web people are pushing for common standards. That takes time and it can get very political, but I don't see a better solution. And if they can get it right, portability is a good thing! I don't see why that necessarily means you'll always be behind the curve on performance. A more standardized, portable system can catch up via economies of scale -- it might be easier to learn, have better tooling, a bigger potential market, etc.

skocznymroczny 9y ago

The recently released Doom game is using OpenGL (and Vulkan).

zanny 9y ago
id has always made opengl engines. They get to deal with endless driver breakage. When Rage came out I believe AMD cards didn't work at all for over a week.
- slavik81 9y ago
  Bioshock was a DirectX game and I recall that shadows were broken on AMD at launch. There are some OpenGL-specific problems with driver breakage, but AMD would be in much better shape today if that's all it was. If you read through the patch notes for your video card drivers, you'll probably notice that every major game release gets special support right in the driver. NVIDIA has three advantages: 1. Most PC gamers have NVIDIA cards, so developers test primarily against NVIDIA cards. 2. NVIDIA has a boatload of driver developers to hack game-specific fixes and improvements right into their driver. They work around game bugs, rewrite slow shaders, and other stuff like that. I assume that's part of why the graphics driver is now well over a hundred megabytes. 3. NVIDIA sends developers to major game studios to optimize and add graphical effects to their games. For instance, volumetric lighting in Fallout 4 was added by an NVIDIA employee. I think AMD does much of the same, but they just don't have the money to do it to the same extent. That means more breakage and slower fixes.

iainmerrick 9y ago

WebGL isn't trying to be competitive with full blown game engines, is it? Sure it is! Not right now maybe, but the web standards people working on it would love to be a viable platform for AAA games. Every so often they tout a new WebGL port of a well-known game as the harbinger of things to come.

bflesch 9y ago
I'd love to build webgl multiplayer games. I hope to get the chance working on these things in the future.
peoplewindow 9y ago
Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? I think they're more concerned with the politics of it than the technical requirements of that userset. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments.
- iainmerrick 9y ago
  (I'm mostly playing devil's advocate here, I don't actually think HTML will be suitable for high-end games in the near future. But I think there are decent arguments to be made...) Then why are they implementing an API that's been unpopular for years and is now being phased out entirely (for AAA games)? Mobile. They picked OpenGL ES 2.0 for WebGL because it had comprehensively won on mobile. Apple went with ES 2.0 and Android followed. It's taking a long time for the mobile industry to migrate to ES 3 (which would allow WebGL 2) but ES 2 has been a decent stable baseline for a good few years now. That's quite unusual, and very helpful, given how fast-moving everything in tech is. [Edit to add: ES 2 is based on GL 3, which was the first version to add programmable shaders. That was a huge API change, and an admission that the D3D approach was better. It's barely 10 years old. So any "GL is unpopular" arguments based on the old fixed-function pipeline are a red herring, I think.] Mobile was and is more important than either desktops or consoles, because the mobile market is huge and growing, while desktops and console are at best stable. Google came up with a clever technical solution (the ANGLE library) to emulate ES 2.0 on top of Direct3D, so that sidesteps the technical problems of OpenGL on Windows. Now, for AAA games, desktops and consoles are obviously far more important. I think there are two responses to that: First, a bet that mobile will gradually catch up and become equally important. There are a lot of factors involved, but on raw technical terms it's not such a bad bet. Mobile hardware iterates very fast, and some mobile CPUs are getting very competitive with desktops (recent iPads and iPhones especially). Sustained performance is an issue, as mobile devices have much stricter thermal limits; but you can put the same mobile SoC in a bigger box, like the TV set-top boxes that Google, Apple, Amazon and others are experimenting with. Second, there's no reason WebGL 3 couldn't be based on Vulkan. WebGL 2 hasn't even been fully adopted yet, so it would obviously take a number of years to make that happen. Maybe desktops and consoles will have moved on to something newer and better by then, but maybe they won't. The big question is whether mobile+web is catching up on desktop+console, or if it'll always be a generation or two behind. I think you'd have to be pretty brave to bet against them ever catching up. I think they're more concerned with the politics of it than the technical requirements of that userset. I'm sure politics plays into it, but for WebGL specifically, it must have been a pretty easy technical decision. Do you pick the 3D standard used on Windows, or do you pick the lower-end one used by iOS and Android (and can be made to work on Windows)? You could ask why GL rather than D3D won on mobile in the first place. For that you have to look at Microsoft and ask why Windows Mobile failed (in all its different versions). I don't think you can blame that entirely on politics. Games are heavy users of driver and card specific extensions for instance. But that'd be at odds with the web's portability commitments. That's a good point. From a web standards standpoint, it's a very tough conflict to resolve. I think the web people are pushing for common standards. That takes time and it can get very political, but I don't see a better solution. And if they can get it right, portability is a good thing! I don't see why that necessarily means you'll always be behind the curve on performance. A more standardized, portable system can catch up via economies of scale -- it might be easier to learn, have better tooling, a bigger potential market, etc.