Due to tooling, sandboxing and not having any control about what GPU gets selected, or why the browser blakckboxes it and switches into software rendering.
The biggest issue is the API limitations that restrict you from doing things a certain modern way, and you have to use more mid 2000s techniques.
Here's a game that uses an Electron powered engine that uses Js and WebGL:
There are times when it is legitimately true, but it's far easier to say that your would have been amazing efforts were blocked because you needed obscure feature of prototype GPU than it is to accept you were never going to get close in the first place for completely different reasons.
Even WebGL 2 is only equivalent of GLES 3.1 (and that's maybe a low 4.1 desktop GL equivalent). I think my "software" raytracing for desktop GL was only feasible with GL 4.3 or GL 4.4 if i remember correctly (And even those are kinda ancient).
For what?
This is exactly what I am talking about: successful 3D products don’t need raytracing or GI, the bulk of the audience doesn’t care, as shown by the popularity of the Switch. Sure those things might be nice but people act like they are roadblocks.
But also, I'm pretty sure that even the Switch 1 has far more capable graphics than WebGL 2. Doom Eternal is ported to it and reading a frame teardown someone did they mentioned that parts of it are using compute.
Yes, you can do fairly cool stuff for a majority of people but old API's also means that you will spend far more time to get something halfway decent (older worse API's just takes more time to do things with than the modern ones).
I do think we're due for a new wave of web-based gaming though, web audio just wasn't near maturity when Flash went and the mobile/steam/xbindie marketplaces still worked for indies. But now with all the crowding and algorithm changes people are hurting and I think it might just be a little spark needed for a major shift to occur.
And that is Flash 3D quality, we would expect something better 15 years later.
And sorry for the lack of quality - this project was built by just one guy who did custom everything (art, engine, editor, writing, music etc.) - it's super impressive imo. I'm sure if you replaced the models and textures with better looking ones (at no increase of technical complexity), it would look better.
- the incredible overhead of each and every API call
- the nerfed timers that jitter on purpose
- the limitation of a single rendering context and that you *must* use the JS main thread to all those rendering calls (so no background async for you..)The calling overhead between WASM and JS is pretty much negligible since at least 2018:
https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
> - - the nerfed timers that jitter on purpose
At least Chrome and Firefox have "high-enough" resolution timers in cross-origin-isolated contexts:
https://developer.chrome.com/blog/cross-origin-isolated-hr-t...
...also, if you just need a non-jittery frame time, computing the average over multiple frames actually gives you a frame duration that's stable and exact (e.g. 16.667 or 8.333 milliseconds despite the low-resolution inputs).
Also, surpise: there are no non-jittery time sources on native platforms either (for measuring frame duration at least) - you also need to run a noise-removal filter over the measured frame duration in native games. Even the 'exact' presentation timestamps from DXGI or MTLDrawable have very significant (up to millisecond) jitter.
> - the limitation of a single rendering context and that you must use the JS main thread to all those rendering calls (so no background async for you..)
OffscreenCanvas allows to perform rendering in a worker thread: https://web.dev/articles/offscreen-canvas
Win32 performance counter has native resolution < 1us
OffScreencanvas is something I haven't actually come across before. Looks interesting, but I already expect that the API is either brain damaged or intentionally nerfed for security reasons (or both). Anyway I'll look into it so thanks for that!
Yes but that's hardly useful for things like measuring frame duration when the OS scheduler runs your per-frame code a millisecond late or early, or generally preempts your thread in the middle of your timing code (eg measuring durations precisely is also a non-trivial problem on native platforms even with high precision time sources).
If you want to correlate the timestamps with wall time then good luck, but if you just need to know how many nanoseconds elapsed between two points in the program on a single thread then that’s your tool.
TL;DR: the precision of your time source won't matter much since thread scheduling gets in the way, one general solution is to apply some sort of noise filter to remove jitter
Yeah, that's an issue, esp with WebGL.. but you can get pretty far by reducing calls with a cache, things like "don't set the uniform / attribute if you don't need to".. but I hear WebGPU has a better API for this, and eventually this should get native performance.. though, I also wonder, is this really a bottleneck for real-world projects? I love geeking out about this.. but.. I suspect the real-world blocker is more like "user doesn't want to wait 5 mins to download AAA textures"
> Nerfed timers
Yeah, also an issue. Fwiw Mainloop.js gives a nice API for having a fixed timestep and getting an interpolation value in your draw handler to smooth things out. Not perfect, but easy and state-of-the-art afaict. Here's a simple demo (notice how `lerp` is called in the draw handler): https://github.com/dakom/mainloop-test
Re: multithreading, I don't think that's a showstopper... more like, techniques you'd use for native aren't going to work out of the box on web, needs more custom planning. I see this as more of a problem for speeding up systems _within_ systems, i.e. faster physics by parallelizing grids or whatever, but for having a physics WASM running in a worker thread that shares data with the main thread, it's totally doable, just needs elbow grease to make it work (will be nice when multithreading _just works_ with a a SharedArrayBuffer and easily)
In standard OpenGL the de-facto way to do parallel GPU resource uploads while rendering is to have multiple rendering contexts in a "share group" which allows them to share some resources such as textures. So then you can run rendering in one thread that uses one context and do resource uploads in another thread that uses a different context.
There was a sibling comment that mentioned something called off screen canvas which hints that it might be something that would let the web app achieve the same.
This isn't really what real-time graphics is all about in modern times.
This is,
https://youtu.be/AV279wThmVU?si=Ou04h5z0Mju7kiJ0
The demo is from 2018, 7 years ago!
It only a way to hopefully get hardware accelerated canvas, if the browser doesn't consider GPU blacklisted for 3D acceleration.
That isn't real time graphics in the sense of games programming.
Basically they define anything less than pushing the extreme limits of rendering technology to be worthless, while simultaneously not actually understanding what that is beyond the marketing hype. The fact most users would not be able to run that seven year old demo on their systems today, even natively, would be beside the point of course.
WebGL particularly absolutely has problems, but the revealing thing is how few people state what they really are, such as the API being synchronous or the inability to use inverted z-buffers. Instead it's a lot of noise about ray tracing etc.
WASM per call overhead is a whole other problem too, GC or not.
In real time graphics quality rendering that is.