[HN Gopher] Show HN: Attempt to bring a cinematic experience in ...
___________________________________________________________________
Show HN: Attempt to bring a cinematic experience in 256 bytes
(WASM)
Author : ilmenit
Score : 115 points
Date : 2024-05-11 20:48 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| vvoruganti wrote:
| Reminds me a lot of demoscening
|
| https://en.wikipedia.org/wiki/Demoscene
| neckro23 wrote:
| This _is_ demoscene, it won first place:
| https://www.pouet.net/prod.php?which=96944
| rmetzler wrote:
| So we're doing WASM demos now?
| ilmenit wrote:
| We are doing demos for all the possible (and impossible)
| platforms ;-)
| squigz wrote:
| What's wrong with that?
| skrebbel wrote:
| Yes!!
| jsheard wrote:
| 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.
| Dwedit wrote:
| I wonder if someone could port Elevated to WebGL, then how big
| would it be? I wonder if it would fit within 64KB.
| ilmenit wrote:
| There was a Javascript port of Elevated in about 13KB, but
| seems it disappeared from the Internet.
| robxorb wrote:
| 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-...
| pushedx wrote:
| Elevated has been on Shadertoy for more than 10 years
| https://www.shadertoy.com/view/MdX3Rr
| butz wrote:
| Amazing, considering whole demo fits in URL. Modern website
| developers should learn a thing or two about optimization from
| this.
| vsnf wrote:
| > 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
| shepherdjerred wrote:
| 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?
| butz wrote:
| 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.
| shepherdjerred wrote:
| 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.
| robxorb wrote:
| 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?
| ilmenit wrote:
| 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.
| flohofwoe wrote:
| 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).
| skrebbel wrote:
| 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!
| bn-l wrote:
| 256 bytes ?!? How is that possible. I misread it as 256K
| initially.
| vlovich123 wrote:
| 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.
| flohofwoe wrote:
| 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.
| vsnf wrote:
| > 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 wrote:
| 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).
| hinkley wrote:
| > 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)
___________________________________________________________________
(page generated 2024-05-12 23:02 UTC)