3 ms·

Runs in any browser, zero install. Meanwhile: Error - The following features required to run Godot projects on the Web are missing: WebGL2 - Check web browser

Runs in any browser, zero install. Meanwhile: Error - The following features required to run Godot projects on the Web are missing: WebGL2 - Check web browser configuration and hardware support This is on Chrome 148.0.7778.96 (Official Build) (64-bit) on Fedora 44, 14900K, 4090 RTX, 128GB RAM 35MB WASM which relies on browser, which relies on drivers and OS, AND it doesn't work as advertised. I get the point, but point was mistaken.

the_duke 5mo ago
This is often due to (privacy) extensions disabling canvas/webgl.
- Keyframe 5mo ago
  FWIW it was because chrome was running from flatpak (ironically).
jdiff 5mo ago
WebGL2 has been supported in Chrome since 2017.[0] The last holdout, as is tradition, was Safari which gained support in 2021. MDN considers it "Baseline - Widely available." [0] https://caniuse.com/webgl2 https://caniuse.com/webgl2
flohofwoe 5mo ago
WebGL2 support on Chrome and Firefox is now nearly a decade old: https://caniuse.com/webgl2 https://caniuse.com/webgl2 Only Safari was late to the party (2021). No offense, but the problem is clearly with your setup.
- Keyframe 5mo ago
  no offense taken. Of course it's my setup, even though it's vanilla setup on a new driver where driver and gfx do work. That's the thing illustrated here - it's always someone's setup somewhere outside of general case tested and "works on my machine". Then you get into all these setups and see variations and one day you decide for common libs to be shipped with your game (remember those MSVC installs?), then still same issues and then you decide to ship common runtime (like steam has), then you decide to ship hardware.. on more constrained (SLAs and whatnots) side it was the same thing and that's how we ended up with docker images.
  - flohofwoe 5mo ago
    > Then you get into all these setups and see variations ...tbf, this is mostly a problem on Linux nowadays. E.g. the MSVC runtime library thing had been solved since Win10 via the "Universal C Runtime".
GuB-42 5mo ago
It is a common argument when sizecoding is discussed. "You say it is 64k, but I need a multi-gigabyte OS to run it...". 35MB can't hardly be called sizecoding, but that's the same idea. It is true, but besides the point because we have no choice. It is not the 1980s anymore and we can't access the hardware directly on personal computers, vendors don't let us. Not that we would want to, for portability reasons. So we depend on abstraction layers, which are not particularly lightweight, and here, it is a working browser supporting WebGL2 and WASM. You simply can't have a game engine running on modern hardware without a software platform. For the sake of argument, we could imagine a lightweight (tens of MB or less) WASM bare metal platform with simple pixel pushing hardware.
beanjuiceII 5mo ago
"works on my machine"
devy 5mo ago
[dead]
mrpf1ster 5mo ago
Does a docker image not also require drivers, an OS, and the Docker Engine?

the_duke 5mo ago

This is often due to (privacy) extensions disabling canvas/webgl.

Keyframe 5mo ago
FWIW it was because chrome was running from flatpak (ironically).

jdiff 5mo ago

WebGL2 has been supported in Chrome since 2017.[0] The last holdout, as is tradition, was Safari which gained support in 2021. MDN considers it "Baseline - Widely available." [0] https://caniuse.com/webgl2 https://caniuse.com/webgl2

flohofwoe 5mo ago

WebGL2 support on Chrome and Firefox is now nearly a decade old: https://caniuse.com/webgl2 https://caniuse.com/webgl2 Only Safari was late to the party (2021). No offense, but the problem is clearly with your setup.

Keyframe 5mo ago
no offense taken. Of course it's my setup, even though it's vanilla setup on a new driver where driver and gfx do work. That's the thing illustrated here - it's always someone's setup somewhere outside of general case tested and "works on my machine". Then you get into all these setups and see variations and one day you decide for common libs to be shipped with your game (remember those MSVC installs?), then still same issues and then you decide to ship common runtime (like steam has), then you decide to ship hardware.. on more constrained (SLAs and whatnots) side it was the same thing and that's how we ended up with docker images.
- flohofwoe 5mo ago
  > Then you get into all these setups and see variations ...tbf, this is mostly a problem on Linux nowadays. E.g. the MSVC runtime library thing had been solved since Win10 via the "Universal C Runtime".

GuB-42 5mo ago

It is a common argument when sizecoding is discussed. "You say it is 64k, but I need a multi-gigabyte OS to run it...". 35MB can't hardly be called sizecoding, but that's the same idea. It is true, but besides the point because we have no choice. It is not the 1980s anymore and we can't access the hardware directly on personal computers, vendors don't let us. Not that we would want to, for portability reasons. So we depend on abstraction layers, which are not particularly lightweight, and here, it is a working browser supporting WebGL2 and WASM. You simply can't have a game engine running on modern hardware without a software platform. For the sake of argument, we could imagine a lightweight (tens of MB or less) WASM bare metal platform with simple pixel pushing hardware.

beanjuiceII 5mo ago

"works on my machine"

devy 5mo ago

[dead]

mrpf1ster 5mo ago

Does a docker image not also require drivers, an OS, and the Docker Engine?