6 ms·
Show HN: Attempt to bring a cinematic experience in 256 bytes (WASM)
- vvoruganti 2y agoReminds me a lot of demoscening https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene
- Dwedit 2y agoI wonder if someone could port Elevated to WebGL, then how big would it be? I wonder if it would fit within 64KB.
- ilmenit 2y agoThere was a Javascript port of Elevated in about 13KB, but seems it disappeared from the Internet.
- robxorb 2y agoHere 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-fly-through-demo-in-28kb-of-javascript/index.html http://creativejs.com/2013/02/elevated-a-beautiful-mountain-...
- pushedx 2y agoElevated has been on Shadertoy for more than 10 years https://www.shadertoy.com/view/MdX3Rr https://www.shadertoy.com/view/MdX3Rr
- butz 2y agoAmazing, considering whole demo fits in URL. Modern website developers should learn a thing or two about optimization from this.
- butz 2y agoJust 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 https://mastodon.social/@tdp_org/112440017216320486
- vsnf 2y ago> 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 https://en.wikipedia.org/wiki/Revealed_preference
- danielledias204 2y agoYes, now we don't have time to look into optimization. Unless it has started to make a profit.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- shepherdjerred 2y ago
- deleted 2y ago[deleted]
- robxorb 2y agoVery impressive! Would it be possible to port to x86/DOS, and keep the same code size? Or is there limitation in the WASM aspect?
- ilmenit 2y agoActually with HellMood (one of the x86 sizecoding wizards the best known for https://news.ycombinator.com/item?id=23002874 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.
- flohofwoe 2y agoI 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).
- skrebbel 2y agoI 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!
- arresin 2y ago256 bytes ?!? How is that possible. I misread it as 256K initially.
- vlovich123 2y agoIt’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.
- arresin 2y agoah ok so this is the compiled and compressed binary. Still, that’s a tiny space for instructions (no matter how they’re represented).
- flohofwoe 2y agoThe 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.
- vsnf 2y ago> 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.
- flohofwoe 2y agoFWIW, I'm seeing the opposite in my home computer emulators (https://floooh.github.io/tiny8bit/ 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).
- hinkley 2y ago> 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)