When Special-K is more mature, I'll probably integrate them- oK communicating with a Special-K shader via uniforms would open up many more interesting possibilities.
Can anyone give a bit of intuition behind the following construction in reticulum?
p:32{x+f[x]*.5-(pos.xy;1)%size.x}/0 0 0
It appears to be some kind of fixed-point iterative approximation: we initialise an accumulator with the zero vec3 (0;0;0) then transform it 32 times by iteratively mapping it by lambda : vec3 -> vec3 where lambda(x) := x+f[x]*.5-(pos.xy;1)%size.x
So if we crank up the number of iterations from 32 to 64 or 1000 or whatever we get a better approximation of the limit, but it looks better -- due to the fuzzier edges -- after a modest number of iterations. (it also takes a lot less effort to compute the fewer iterations we do).
This produces a vec3 of the screen-space coordinates of the fragment, scaled to a -0.5 to 0.5 range (assuming a square display) and the z component will be the scaling factor. This also happens to invert the axes, which doesn't matter.
x.xy*:mat[cos a;sin a;-sin a;cos a]
This is a standard 2d rotation matrix- rotate the position xy about the origin by angle a.
Your comment is a good description of the overall algorithm.
Wow his is cool. Very nice work! Apl's seem like the perfect fit for this kind of thing and feels like a great way for people to cut there teeth on something like k. Hopefully the syntax will become a moot point since 1/2 the code I love reading are algorithmically terse (and clever)... I hope this gets picked up by the demo or 'tweetcart' like scenes. Theyre always a source of inspiration.
The syntax definitely hurts adoption but I don’t think it’s due to google unfriendliness. The whole language is very small, so the usual need to google for documentation doesn’t seem to apply.
The real barrier to adoption is likely the same with most non-mainstream languages: unpopularity is a vicious cycle, just as popularity is a virtuous one.
Sure, GLSL is easy to learn, because it's basically a simplified C, which many people are already familiar with. It's intentionally bare-bones, verbose and old school, so that everyone can learn it and every vendor won't get bogged down writing compilers for it. In that sense, it achieves its purpose well enough.
But come on, it doesn't even have first-class functions. There are countless examples of unreadable macros and code duplication out there due to GLSL's extreme simplicity.
I have never seen anyone think GLSL needed first class functions. Can you give me an example of how you would use them instead of a macro? GPUs can't jump to a function pointer as far as I know and macros can't be passed to functions.
Functional programming can make advanced shaders -- particularly distance field stuff -- significantly simpler. I pass first-class functions around all over the place in this example, which compiles down to GLSL: https://github.com/daeken/DaeForth/blob/master/FragmentToy/t...
A good example there is `twist-func' which takes in a world-space position, a block that hands back a twist factor, and a block that receives the transformed position (in object space). Once you start doing things that way, you end up with ridiculously rapid development, which is the whole reason I created this family of languages; started as an experiment to take APL/K, Lisp, and Forth and smash them all together, and it ended up working out well enough that I've kept it going for 7 years now.
If you scroll down to the section "Deformations and distortions", you'll notice that iq wishes so hard there were first class functions in GLSL that he pretends they exist in all the code examples (the deformation functions all take functions as parameters).
As for macros specifically filling in the role of first class functions, this is sometimes done by creating a macro that takes a function as parameter. So for example, iq's functions above could be turned into crazy macros.
Special-K is a subset of the k6 dialect of this language, in part due to the constrants of GLSL, which retains its concise nature and which should be intelligible and convenient for those who already know K. For those who do not yet know K, it may still be a pleasant way to experiment with fragment shaders.
For people who don't know this one: another JS based version of k: http://johnearnest.github.io/ok/ike/ike.html
(without the glsl)