Live data from Hacker News

Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

github.com

21–30 of 33 posts

Re: Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

#21
post #19

> or click the following link if you have the FireFox browser (Chrome’s implementation of WebAssembly has much worse performance). Now that is interesting. I've been on the FireFox train for 20 years but I haven't seen a "best viewed in FireFox" tag in a long time. It's a pleasant surprise, but I'm also curious how Chrome has managed to be bad at this.

FWIW, I'm seeing the opposite in my home computer emulators (https://floooh.github.io/tiny8bit/), which are compiled from C with heavy bit-twiddling on 64-bit integers. Firefox is slightly slower than Chrome (on an M1 Mac) - but not enough to matter much (around 5..10% or so).

It might be heavily depending on the actual 'instruction mix' and host CPU instruction set (e.g. maybe Firefox has better support for x86 than ARM).

Re: Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

#22
post #18

256 bytes ?!? How is that possible. I misread it as 256K initially.

The code is quite similar to a GPU shader function, and it's running on a "fantasy console" which basically gives you a 320x240 pixels framebuffer to poke into (and the code used to implement the fantasy console isn't counted).

Same reason why doing things like this on old home computers or a DOS PC can also be done in a few hundred bytes of bare metal code, because the hardware implements most of what today is called a "rendering engine" and implemented in software.

Re: Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

#23
post #14

Very impressive! Would it be possible to port to x86/DOS, and keep the same code size? Or is there limitation in the WASM aspect?

I wouldn't be surprised if the same code ported to the x86 instruction set would be more compact before compression (after compression probably closer to each other).

Re: Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

#25
post #5
post #3

Earlier quoted context omitted.

This is demoscene, it won first place: https://www.pouet.net/prod.php?which=96944

So we're doing WASM demos now?

Why not? It's a good way to keep the spirit of retro sizecoding going but in a way that's easier to share on modern platforms.

Re: Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

#27
post #6

Amazing, considering whole demo fits in URL. Modern website developers should learn a thing or two about optimization from this.

If you were running a company, how would you justify spending developer time on such an optimization versus, say, implementing features that actually make money?

Re: Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

#28
post #6

Amazing, considering whole demo fits in URL. Modern website developers should learn a thing or two about optimization from this.

If you were running a company, how would you justify spending developer time on such an optimization versus, say, implementing features that actually make money?

Depending on your market, your target users might not be using the latest and fastest devices on latest 5G network or optic. If user goes through checkout flow as fast as possible, company makes money faster.

Re: Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)

#29
post #28

Earlier quoted context omitted.

If you were running a company, how would you justify spending developer time on such an optimization versus, say, implementing features that actually make money?

Depending on your market, your target users might not be using the latest and fastest devices on latest 5G network or optic. If user goes through checkout flow as fast as possible, company makes money faster.

Yes, but as you said, this is very market dependent. I'm all for optimization where it's needed, but often times optimization hasn't been done because it isn't needed, e.g. in the case of electron apps.
Post reply on HN