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

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).

Elevated has been on Shadertoy for more than 10 years https://www.shadertoy.com/view/MdX3Rr

There was a Javascript port of Elevated in about 13KB, but seems it disappeared from the Internet.

Actually with HellMood (one of the x86 sizecoding wizards the best known for https://news.ycombinator.com/item?id=23002874) we were working on a port to FreeDOS x86/FPU, but the personal time did not allow us to finish the port before the competition deadline. Quoting HellMood "i think now that a decent port is possible". There are a few advantages of WASM/MicroW8 like ability to draw vertical lines, or a palette that can use 8bit RGB (while VGA has 6bits), but the x86 in 16bit real-mode has powerful short CPU and FPU instructions, and you can use code as data (e.g., for IEEE float constants) to further reduce the binary length.

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).

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.

It’s literally in the link.

A non-specified amount of code in the MicroW8 runtime which isn’t included in that 256 bytes to implement the graphics layer (320x240 256 colors 60hz) and gives you 256 kib of memory.

256 bytes is the “cartridge” to run on this platform with compression.

It’s still extremely impressive because of the creativity of the generative visual effects they figured out how to fit in 256 bytes.

> Modern website developers should learn a thing or two about optimization from this.

I'm just as anti-bloat as the next HN'er, but optimizing websites is almost certainly not a business interest, therefore not an imperative, and therefore not going to happen. Instead of just wishing web developers were better, it would be more productive to find a way to align website optimization with business interests.

After all, how many people, really, would stop using websites or apps because they're slow? They can be frustrating, but most of the non-tech people I know just deal with it. That's hardly a recipe for changing the way websites are built. Basically, I posit to you that website, webapp, and mobile app optimization is a revealed preference [0], where the preference is that it's not actually important.

[0] https://en.wikipedia.org/wiki/Revealed_preference

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?

Just a follow up to all downvoters: developers care, and are working on improving performance, take a look at one of hopefully many to come, examples - https://mastodon.social/@tdp_org/112440017216320486

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