3 ms·

At this time I would recommend WebGL 2. WebGL 2 is finally supported in all major browsers now that Safari 15 shipped. WebGL 2 has some of the benefits mentione

At this time I would recommend WebGL 2. WebGL 2 is finally supported in all major browsers now that Safari 15 shipped. WebGL 2 has some of the benefits mentioned in the article for WebGPU, such as a reasonable minimum texture size (2048 vs 64 in WebGL 1) and the built-in ability to get the size of a texture in a shader. WebGPU will not ship in all browsers for some time, and when it does it will not have have wider hardware support than WebGL 2. It has the potential to be faster in some cases, but the difference is unlikely to matter for most. The big draw of WebGPU should be compute shader support, though it is definitely possible to do compute work in WebGL 2 either with transform feedback or just regular shaders.

hajile 5y ago
It is currently shipping behind a flag in desktop versions of Chrome (and all its derivatives), Safari, and Firefox. It is also shipping behind a flag in Firefox for Android. I don't think it's too far out from finally shipping. The biggest boon would be for mobile devs to help avoid the 30% store tax, but this is also the reason why mobile Chrome and mobile Safari (especially Safari) tend to lag behind in major ways.
- modeless 5y ago
  What Safari is shipping behind a flag is not anything like the current version of WebGPU. I don't think it supports WGSL, for example. It's going to be a long time before all three browsers have shipped implementations that are interoperable and not behind flags. I don't think WebGPU is the biggest thing that's going to let mobile game devs start shipping on the web. WebGL 2 can do graphics well enough today. Other things hold the web back. Monetization is the big thing that people always talk about. The lucrative interstitial app install ads that mobile games have aren't on web, and in-app purchases have a lot more friction. Handling large binary assets is also a place where the web is lacking and WebGPU won't fix that. Finally, there's a lot of ecosystem and tools stuff that needs to happen too. The engines need to add web platform support which goes more than skin deep. Shipping a game as one giant binary is not good enough for web, you need to split your code into dynamically loadable modules and stream your assets. You need Basis Universal compressed textures. Etc. Fix all of the above and then web games can shine, with or without WebGPU. Realistically, fix monetization and the rest will follow. Big caveat though: I think many see the monetization techniques currently used by mobile games as exploitative. It's not clear that you could do web game monetization competitively without the same level of exploitation.
  - snuser 5y ago
    I play a lot of web games without any of that stuff now
    - modeless 5y ago
      There's definitely a niche market out there, I think https://poki.com https://poki.com exemplifies it. Which ones do you play?
      - snuser 5y ago
        BGA and basketball gm
- pjmlp 5y ago
  Web 3D APIs are castrated, they will never be able to match native APIs. Going for GL ES 3.0 subset, when devices do GL ES 3.2? Going for a MVP 1.0 with minimum overlap across Metal, Vulkan and DX12 instead of using their full blown capabilities? In both cases, having to use native GPU debugging tools anyway. Rather give the 30%.

hajile 5y ago

It is currently shipping behind a flag in desktop versions of Chrome (and all its derivatives), Safari, and Firefox. It is also shipping behind a flag in Firefox for Android. I don't think it's too far out from finally shipping. The biggest boon would be for mobile devs to help avoid the 30% store tax, but this is also the reason why mobile Chrome and mobile Safari (especially Safari) tend to lag behind in major ways.

modeless 5y ago
What Safari is shipping behind a flag is not anything like the current version of WebGPU. I don't think it supports WGSL, for example. It's going to be a long time before all three browsers have shipped implementations that are interoperable and not behind flags. I don't think WebGPU is the biggest thing that's going to let mobile game devs start shipping on the web. WebGL 2 can do graphics well enough today. Other things hold the web back. Monetization is the big thing that people always talk about. The lucrative interstitial app install ads that mobile games have aren't on web, and in-app purchases have a lot more friction. Handling large binary assets is also a place where the web is lacking and WebGPU won't fix that. Finally, there's a lot of ecosystem and tools stuff that needs to happen too. The engines need to add web platform support which goes more than skin deep. Shipping a game as one giant binary is not good enough for web, you need to split your code into dynamically loadable modules and stream your assets. You need Basis Universal compressed textures. Etc. Fix all of the above and then web games can shine, with or without WebGPU. Realistically, fix monetization and the rest will follow. Big caveat though: I think many see the monetization techniques currently used by mobile games as exploitative. It's not clear that you could do web game monetization competitively without the same level of exploitation.
- snuser 5y ago
  I play a lot of web games without any of that stuff now
  - modeless 5y ago
    There's definitely a niche market out there, I think https://poki.com https://poki.com exemplifies it. Which ones do you play?
    - snuser 5y ago
      BGA and basketball gm
pjmlp 5y ago
Web 3D APIs are castrated, they will never be able to match native APIs. Going for GL ES 3.0 subset, when devices do GL ES 3.2? Going for a MVP 1.0 with minimum overlap across Metal, Vulkan and DX12 instead of using their full blown capabilities? In both cases, having to use native GPU debugging tools anyway. Rather give the 30%.