the different parts of spill

spill renderer
behave engine
dragon representation
spill language

spill renderer

cellpond uses a 2d canvas as a flex, using a kind of dithering approach. it’s built with a different set of assumptions to what spill has, so i would personally replace it with a webgl shader instead that takes cells as vertices or instances or whatever and it draws them instantly via that. note: i wouldn’t use a fragment shader. i think that would be a trap in this case, as it would require a lot of iteration for each pixel, due to spill’s necessarily weird data structure (because of splitting and merging)

behave engine

the lowest level of behaviour in cellpond is the ‘behave’ function, which is what dragon compiles down to. we probably want the same thing in spill. the big difference here is that we’ll need and want to store colours as rgb rather than splash. the format of that rgb value will probably have to be decided by performance testing as it’s an extremely hot path, so it’s fine to pick anything for now and come back to it later.

dragon representation

dragon is an intermediate representation between cellpond’s visual language (colourtode) and the thing that the engine actually runs (behave functions).

one clear change is to make dragon deal with rgb numbers rather than splash numbers. this will vastly simplify spill’s version of dragon. spill will also want much greater customisation of individual rules - we may want to add more parameters on top of chance, etc…

also, in cellpond, dragon does a lot of static unrolling of dynamic rules, ie: transformations, redundant rules. and it completely rebuilds rules after every change. this is under the assumption that rules change rarely - only when the user drags and drops something. in spill, this is different so this should be re-approached to factor in new performance considerations. at this point, i would recommend keeping the transformation and redundant unrolls but in the future, we may want to add support for changing rule registrations without building them from scratch, or perhaps even adding more static unrolls to help enable this.

finally, the stamp system needs to be pulled out and replaced with spill’s symbolic one instead. this is probably a deeper change

spill language

this is the part that is most obviously different from cellpond. it uses a text language instead of a visual one. regardless, it still needs to target dragon. the way it targets it depends on the exact changes that happen to dragon (outlined above).

i also know very little about how to implement a strudel-like language / uzu language. the language part will be a whole other thing!!!

meta stuff

zooming out…

there will be so much baggage to get rid of that i would personally start with an empty file and gradually pull pieces bit by bit into it, adapting it along the way. the first thing would be making the webgl renderer.

cellpond is a very low level thing, so my advice is to keep it low level: deal with data and functions, avoid all abstractions. performance is a key concern so low level as possible is helpful when unpicking bottlenecks.

ultimately, the output of the spill repo will be two things:

a library that you can import into other projects. ideally just a file like spill.js that you can drop into your repo and import from to create the four pieces covered above.
a demo project for building and testing out spill and maybe we can host it on a website. but this is not the main thing. the main thing is spill.js so that we can use it in nudel!

join in with spill development on codeberg

back to the spill