Hacker News Reader

Comment by vbezhenar | Hacker News Reader

Popular apps will be as slow as user can tolerate. Because if they're not slow enough, it invites developers to introduce another abstraction layer.

Good thing is, that it's possible to create truly groundbreaking apps using non-conventional techniques, as web becomes faster and richer with new APIs.

For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome.

I have one example to prove my words. I used iPhone 4S. With iOS 6 I was able to use navigator software which worked very snappy and awesome. Few years later with iOS 9, navigator was very slow, forcing me to buy new phone eventually. With iPhone 8 it returned to blazing fast. But it did not have any new functions. They just started to consume more memory, just because they can. My UX did not change a little bit. I just had to buy new phone with infinitely faster CPU and loads of RAM, just to keep my UX from degrading.

View on HN

This reminds me of Parkinson's law (https://en.wikipedia.org/wiki/Parkinson's_law). Paraphrased: "complexity expands so as to fill the time available for its consumption". The faster a software can be, the more things it seems to do just for achieving the same features.

It's also probably another view of the Jevons Paradox: as efficiency of software increases, it gives more way for more complexity and "optimizations" that in the end make the end result as slow as before.

> Paraphrased: "complexity expands so as to fill the time available for its consumption"

That's a very liberal paraphrasing. Parkinson's law is specifically about the amount of time that it takes to complete work (by humans, e.g. for a project deadline).

If you want to reference something that serves as good commentary about software performance, Wirth's law is right there for the using.

> For example with Wasm and WebGPU it's possible to create AAA games running in the browser.

This has been promised since at least the WebGL and asm.js days. It still won't happen, but not mainly for technical reasons, but for business reasons.

...but of course also some technical reasons. Asm.js/WASM and WebGL/WebGPU are fine, but most other web APIs are a mess and the web is a highly unstable platform, APIs are deactivated or deprecated on a whim, APIs change behaviour unpredictably, behaviour differs between browsers, etc etc...

TL;DR: the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground.

> the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground

Why? We can already play AAA games on our computers. It works very well, much better than anything web-based. Why would anyone put effort into replicating the same thing inside the browser?

Mostly independence from the whims of platform owners who control the distribution, a space to try out quirky new ideas, and less hassle both for devs and users (no lengthy download or installation process for instance).

This is much more important for indie devs than AAA devs though (the current problems of the web platforms are not really 'AAA specific').

Also, don't forget that PC gaming could very well have died out during the transition from DOS to Windows without Microsoft actively supporting game development on Windows (with the DirectX APIs), without this, AAA gaming could very well be console-exclusive now.

> Mostly independence from the whims of platform owners who control the distribution

Agreed, however platforms that restrict app distribution also heavily restrict what you can run via the browser (see Ios). So the benefit is minimal.

> a space to try out quirky new ideas

This has nothing to do with web. Look at steam's catalog. Plenty of whacky quirky stuff is available.

> no lengthy download or installation process for instance

Why do you think AAA games will not need downloading assets and logic?

> This is much more important for indie devs than AAA devs though

I agree, but this is a solved problem with Steam. No need to develop your own over the web.

> Why do you think AAA games will not need downloading assets and logic?

As internet connections get faster it makes sense to stream/prefetch data directly from CDNs as needed instead of downloading everything upfront.

> Look at steam's catalog. Plenty of whacky quirky stuff is available.

Agreed, but that's the exception, not the rule. Look at Apple's app store ecosystem for a counter example where apps and developers are banned on Apple's whim. This couldn't happen on the web.

Is webGPU fine?

https://github.com/gpuweb/gpuweb/issues/566

Basically. Rather than doing something better w3c is designing by committee so hard it somehow made worse OpenGL.

A fellow contributor, that had to deal with pain of OpenGL, laughed this shit out of the gate.

And I mean look at it. Who in their right mind looked at that and said, yeah that looks decent.

Apparently wgsl was created because SPIR-V isn't well suited for being an intermediate representation to target graphics APIs other than Vulkan itself. Some notes of intrest: https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html

Had a discussion with that colleagues I spoke. He pointed me to some interesting discussion in FNA Discord.

Basically bunch of stuff listed in that blog are Rust specific uint vs int.

Others are kinda standards problem of undefined behavior being well - undefined. Gamedevs are used to this, but not Rust devs.

I'm reminded of xkcd https://xkcd.com/927/

So rather than relying on previous work, they wrote their own somehow ugliest standard.

None of what's outlined on that blog has anything to do with Rust. And wgpu has to validate code for undefined behavior because it needs to run in browsers, as well as translate it to other backends that aren't SPIRV--it again doesn't really have anything to do with Rust. In fact according to the Rust memory model, most UB on the GPU would technically be okay (though obviously not ideal) but not in the context of a browser. So just saying "eh that stuff is undefined" or "this is just Rust stuff" doesn't really address the issues outlined there.

Admittedly I don't know kvark, but some of his statement there were wrong, in a way that gives impression he didn't do much 3D programming before hand. That's why I imagine he worked on the If one were to go through a point by point rebuttal, it'd go like this:

- Not knowing you need to have entry point for the shader to be executed.

- kvark's complaint about OpFmod being misnamed are kinda missing the point, % isn't the mod operator but remainder operator (in C/C++)

- https://mobile.twitter.com/TheSpydog/status/1232819839888166... You know it's a pretty bad idea when Unity and Adobe are begging you not to do this.

- I mean what you prefer to write?

GLSL:

    int a = 2
    for (int i = 0; i < 4; i++) {
       a *= 2
    }

WSGL:

    const a: i32 = 2;
    var i : i32 = 0;
    loop() {
       break if (i >= 4);

       a = a * 2;
    
       continuing {
          i = i + 1;
       }
    }

kvark is a GPU expert who's worked on GPU programming, 3D games, and GPU standards for years now. And he's not the only one working on naga, either.

I'm also really not sure how you got the first point from what he wrote. He was not saying he was surprised to find "you need to have an entry point" he was saying the restriction made no sense, and that existing tools didn't even take advantage of having more than one entry point due to driver bugs.

The rest of your points are basically just opinions masquerading as something else. In any case I don't actually care how hard WGSL is to write, because I don't have to write it (you can go through a translation layer). What I'm not going to do is pretend that SPIR-V is a great choice for this intermediate layer solely on the basis of what I've heard from other graphics people who haven't actually tried to use it for that purpose--which is exactly what the article is about.

Kvark's good, but he's still fallible. And I don't know what games he made, but I can tell you, others that had experience with shipping games/software, laughed his articles out loud.

> he was saying the restriction made no sense

So presented with reality of a complex, buggy drivers, his solution is - to ignore it? Wow imagine in UTF-8 people just said, yeah 8bit 0 are ok everywhere and caused hundred of billions of lines of code to be written to deal with null mid UTF8 stream.

> I don't actually care how hard WGSL is to write

Awfully dismissive. Well, ok, you won't have to write it but someone will. And those someone are going to curse whoever wrote that abomination of a spec.

A spec that: - That doesn't respect backwards compatibility - Looks like pure torture to write in - Misunderstands some part like OpRem

I'm not very confident in it to be honest. Looks to me just another overly elaborate moat for browser implementors.

Ugh, please not this again. Considering the alternatives, WGSL is fine. It could have been much worse (e.g. Apple jumping ship and doing their own thing just because they have a problem with Khronos), and not requiring web apps like shadertoy to download and run a shader compiler WASM blob is also a good thing. WebGPU also needs to cover other scenarios than games.

I've always wondered why nobody built Kongregate 2.0 using modern web technologies. The indie game dev scene seems to be thriving, and you can play tons of games for free on itch.io While some of them have a webplayer, it's disorganized, and the user experience is usually terrible.

In its last few years Kongregate was largely JS games.

That didn't help the large move to mobile gaming by its primary audience (which I'm guessing was teens).

Towards the end Kongregate became a platform for idle games that pushed users hard towards pay to win. Sucks, but they grew huge off the glory days of ad revenue and I presume they had to do something to keep surviving.

What are the business reasons? Surely the web is just a platform for delivery? Payment etc can happen through the browser.

I agree, but tell that to the "money people" in big game studios ;) The web simply isn't on their radar, even mobile isn't for the most part. They want strong centralized platforms like Steam, EGS, Xbox, Playstation or Nintendo and a platform owner to negotiate with.

This can change very quickly if there's actually some breakthrough web game, but that hasn't happened so far, and nobody wants to be the first to take the risk.

Both Unreal Engine and Unity already have Google Stadia for a compile target ( Debian/vulkan )and it runs in the browser. As consoles have become more and more generic and all carry a browser, less money is being invested in platform specific engines because there is less relative performance increase & return on investment compared to the past. ( Games sold the platform, not the other way round ) Risks have been taken by big players and everything is becoming more and more platform agnostic therefore we could reasonable expect "breakthrough" when they are done milking the cow previously invested in and see them expand to a bigger market.

> ...and it runs in the browser

That's not correct though, the game runs on a Linux box in Google's datacenters (granted, from a business perspective that's nitpicking - but not quite, see below, but it's a massive difference from a technical perspective).

Scaling to large audiences is much more expensive with the game streaming approach though (but we'll never really know because Stadia bombed, just as all other game streaming platforms before).

It's not just a remote control video feed ( Unlike other game streaming platforms ) so there is tons of incentives and capability for them to offload as much as possible onto the client.

> TL;DR: the web needs a proper "DirectX initiative" like what Microsoft did in the late 90's to get Windows gaming off the ground.

You want one browser vendor to implement a proprietary API and then have the ramining vendors try to emulate it?

Well that's what Google already does anyway with web APIs, except that their APIs are usually a broken mess (see WebAudio).

But apart from that, Microsoft was in a unique position to dictate standards to GPU vendors, as draconian as it sounds, this worked much better than Khronos' design-by-committee approach in OpenGL.

>For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome.

Carmack already tried to do it with Quake Live. It did not go far.

Quake Live didn't run in the browser. It used the browser as a UI for configuration and connecting to the servers but the game itself ran as a native plugin.

If only we can charge a price for taking up too much ram or cpu cycles.

Just don't use it?

>For example with Wasm and WebGPU it's possible to create AAA games running in the browser. Someone will do it. It'll be awesome.

You get a shitty distribution model (relying on browser for cache or limited localstorage, or whatever you want it's shitty in the browser and inconsistent, browsers aren't built to handle GB sized assets).

You pay the sandbox tax even in the ideal scenario and there are plenty pathological ones. And even if you aren't performance constrained you're adding battery drain for no benefit.

Then there's the shitty input model and interaction with browser chrome.

And what are the benefits exactly ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer.

> And what are the benefits exactly ?

Slightly off topic but I wonder if WASM and the web can provide a “fixed” virtual platform for games.

A lot of games are heavily platform dependent, when the hardware for those platforms die the games will be nigh unplayable without a huge remastering effort or building an emulator of said platform which may or may not be technically feasible - even on PC we have games breaking as hardware advanced, e.g. Deus Ex had to be patched to work with multi core CPUs if I remembered right.

>And what are the benefits exactly ? Avoiding app stores ? Might benefit the developer but not really a benefit for the consumer.

well, if a company can avoid paying a significant portion of revenue to an app store they might be able to hire better or more developers which might conceivably be a benefit for the consumer.

Does your experience as a consumer not suggest that the amount of developers employed is, if at all, inversely correlated with software quality?

no, it suggests that just as the amount of developers past a certain point on a project is a drag on that project the amount of developers of a product past a certain point does not significantly increase the quality of that product.

If indeed the amount of developers employed was inversely correlated with software quality then the best software is that which does not exist. I realize there is a pithy saying that the best code is no code at all but I am not especially fond of such illogical pithiness.

There may be products that it is best they not exist at all, but for products we do want to exist it follows that some number of developers of that product correlates with the quality of its existence.

I was thinking in terms of Amdahls and Brooks law. Of course zero is an edge case, but in my experience the best designs in terms of quality (not number of features) come from individual work. You can not scale this part out.

I think they were making a point about performance.

> GB sized assets

You don't need such assets to make good games anyway. The obsessions with AAA are unhealthy - many of the best games are not AAA at all, but strictly indie.

Some people can't wait until all games are proper Electron apps

Reply on news.ycombinator.com