Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM) (github.com/ilmenit)
133 points by ilmenit on May 11, 2024 | hide | past | favorite | 29 comments


I was at Outline Demoparty last night where this was in the compo and we were all blown away. The crowd went proper mad, hats off.

Everybody was already super impressed when it was just sea waves, because they looked much better than one would expect in a 256b compo. And when the weird egg thing came and exploded, our minds did too.

Deserved win!


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


> or click the following link if you have the FireFox browser (Chrome’s implementation of WebAssembly has much worse performance).

The 20% of users reading this on mobile Safari: am I a joke to you?

(It works fine on iPad Mini)


I wonder if someone could port Elevated to WebGL, then how big would it be? I wonder if it would fit within 64KB.


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.


Here it is in 28KB. The site also links to a 9KB version (but it didn't work for me):

http://creativejs.com/2013/02/elevated-a-beautiful-mountain-...


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?


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


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.


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.


ah ok so this is the compiled and compressed binary. Still, that’s a tiny space for instructions (no matter how they’re represented).


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


> 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


Yes, now we don't have time to look into optimization. Unless it has started to make a profit.


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.


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


Reminds me a lot of demoscening

https://en.wikipedia.org/wiki/Demoscene


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


So we're doing WASM demos now?


We are doing demos for all the possible (and impossible) platforms ;-)


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.


What's wrong with that?


Yes!!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: