puls (256 bytes)
Why Hacker News recommends it
HN commenters cite it as the most impressive 256-byte production and as an example of how much graphics code can fit in a tiny binary.
What it is
A 256-byte MS-DOS intro that renders a raymarched, procedural 3D animation. It won the 256-byte competition at Riverwash 2009 and the scene.org award for best technical achievement that year, and the author published commented x86 assembly source.
Recommended by 1 HN commenters across 1 different months, 2011 to 2014.
What Hacker News said
Recommends psykotic · 2011-08 · on “Low-level x86 code compression for 64k intros”
Neat hack! But stacking sine waves with a bit of modulation isn't exactly earth-shattering. You might like to try some of these: [LINK] . The most impressive to date is probably Puls: [this video] . The top three 256b productions on Pouet are all doing the same basic thing of ray marching against an isosurface. The sophistication of the geometry has increased a lot since Lattice, which used something simple like cos(x)^2 + cos(y)^2 + cos(z)^2 = f(t) where f(t) is an oscillatory function of time that controls the thinning and fattening of the lattice.
Cites chengsun · 2014-04 · on “Evolutionary algorithm to find Quake III's fast inverse square hack with Python”
Řrřola (a famous demoscene coder [1]) found a far better constant than the original (a 2.7-fold accuracy improvement) by using an optimisation algorithm over all three constants present in the original inverse square hack. His algorithm and the result (along with a plot of relative error) can be found on his blog [2]. [1]: See, for example, this 256-byte raycaster [this video] [2]: [LINK]
Cites userbinator · 2014-10 · on “Intel Underestimates Error Bounds by 1.3 Quintillion”
> You really don't want to use x86 hardware transcendental instructions ...unless you're doing size-optimised graphics intros, where tremendous accuracy is not essential and the stack-based nature of x87 makes for some extremely compact code: [LINK] [this video] I think the main reason why this issue hasn't been so significant is that the majority of code that uses those instructions isn't dependent on extreme accuracy - code that does would likely use their own routines and/or even arbitrary-precision arithmetic.