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.
Why Hacker News points people here: 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.
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 itchengsunApr 2014
“See, for example, this 256-byte raycaster”
Example of the coder's 256-byte raycaster.
Full comment
Ř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 ituserbinatorOct 2014
“size-optimised graphics intros, where tremendous accuracy is not essential”
Example of compact x87 code in size-optimised graphics intros.
Full comment
> 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: linkthis 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.
