Super cool shader toy! Semi-related, but my favorite demo ever (a tiny 64k Heaven Seven[1]) was fully coded in extremely esoteric assembly and used all kinds of mind-blowing tricks. There's a blog post written about it somewhere by a few Exceed members; real-time raytracing on a CPU in 2000 still blows my mind.
My bud was learning assembly but the normal material was pretty boring but I know he wanted to learn shaders so I combined the two into
something pretty terrible. It has all the same complexity of normal raymarching, sdf defining, space coordinate warping, except now
you dont get variables or functions.
At first it was just a cpp demo with vm that run per pixel. That was slow, but threading it made it plenty fast for whatever peak compute
you might need for a shader written in asm. Then added inputs to match shader toy, buffers for feedback and memory, and various inputs, mouse, kb, mic, webcam, etc. After that i looked over the examples and... found them pretty bland. The asm was missing things needed to make it more of an asm and less of a riscv'ish LHA form. So we add features: registers, labels, branches, subr, includes, consts, etc.
Theres a clever two eval pass for consts that is inspired by lisp, where the consts are just the same asm but with a different env. I did it
like that because I looked at real asm const DSL's and they look impure to me and violate the intention of the project.
Its sort of like comptime if you know what that is and dont know lisp. (What are you retarded?)
I know asm's have lots of funny macro ideas that can make them like pseudo real languages, but I just left that out because at that point
why not write a little scheme that targets this "ST-ASM" as an IR, and then a tabbed pseudo python with swizzling that lowers to that.
Ill probably do that next for fun.
To share it it had to be on web, and cpu vm per pixel wasnt gonna cut it in js. So the browser version now compiles the assembly to WGSL for WebGPU, with a WebGL2 fallback so Firefox can still run it. (Took longer to get that working than the entire rest of the project, but if it cant run on the top browsers then it can't be shown off...)
Super cool shader toy! Semi-related, but my favorite demo ever (a tiny 64k Heaven Seven[1]) was fully coded in extremely esoteric assembly and used all kinds of mind-blowing tricks. There's a blog post written about it somewhere by a few Exceed members; real-time raytracing on a CPU in 2000 still blows my mind.
[1] https://www.youtube.com/watch?v=-Qw5bavWxBs
My bud was learning assembly but the normal material was pretty boring but I know he wanted to learn shaders so I combined the two into something pretty terrible. It has all the same complexity of normal raymarching, sdf defining, space coordinate warping, except now you dont get variables or functions.
At first it was just a cpp demo with vm that run per pixel. That was slow, but threading it made it plenty fast for whatever peak compute you might need for a shader written in asm. Then added inputs to match shader toy, buffers for feedback and memory, and various inputs, mouse, kb, mic, webcam, etc. After that i looked over the examples and... found them pretty bland. The asm was missing things needed to make it more of an asm and less of a riscv'ish LHA form. So we add features: registers, labels, branches, subr, includes, consts, etc.
Theres a clever two eval pass for consts that is inspired by lisp, where the consts are just the same asm but with a different env. I did it like that because I looked at real asm const DSL's and they look impure to me and violate the intention of the project. Its sort of like comptime if you know what that is and dont know lisp. (What are you retarded?)
I know asm's have lots of funny macro ideas that can make them like pseudo real languages, but I just left that out because at that point why not write a little scheme that targets this "ST-ASM" as an IR, and then a tabbed pseudo python with swizzling that lowers to that. Ill probably do that next for fun.
To share it it had to be on web, and cpu vm per pixel wasnt gonna cut it in js. So the browser version now compiles the assembly to WGSL for WebGPU, with a WebGL2 fallback so Firefox can still run it. (Took longer to get that working than the entire rest of the project, but if it cant run on the top browsers then it can't be shown off...)