1) The order the shapes are drawn is undefined.
Alas, we already violate this principle: The brightness is defined in such a way that the order of drawing matters, since the shade of the shape is opaque. This is problem we should consider fixing ASAP. When we expand into the realm of color, we will face this again.
2) The choices made in one expansion cannot affect any other expansion.
Another way of saying this that no information can "leak out" from one expansion and be used in another. This rules out possible extensions like global variables, maximum rule use counts and rule return values.
Keeping to these restrictions is more than just "nerd purity". The ability for the program to process the grammar files efficiently is predicated on them.
Already, the order of rule expansion and shape drawing will vary depending on the size of the image: When we reach a million shapes or two million expansions, the program starts to write things out into temporary files, and this alters the order of operations.
Another example is that the pruning of sub-pixel rules can be done because we know that their expansion can't affect other expansions.
Lastly, John already has plans in the works to take advantage of systems with multiple CPUs and/or hyper-threading and compute parts of the image in parallel.
On the other hand, things like parameterized rules (rule arguments) don't actually violate the context free nature. They simply form a short hand for a large family of rules. Formally, this is actually what is happening with the x, y, size, rotation and brightness values at present.
So I could imagine extending CFDG to allow things like:
Code: Select all
rule curve($shape) {
$shape { }
curve { rotation 1 y 0.5 size 0.975 }
}
I feel like once we've seen a hundred good designs with the current CFDG, then we'll know what we'll need to add. And when we do, we should try to stick to what makes CFDG work so well: a minimal set of features that results in an astonishingly wide variety of very wonderful images.
If I really must admit to what I'm currently thinking about, it is this set of additions, in rough order:
- fix the brightness problem
- add something like a simple TRIANGLE(a) primitive which draws a triangle with angles a, 90-a and 90, the hypotenuse where the diameter of CIRCLE would be drawn. All the other polygons and triangles can be constructed with finite rules from this. An equilateral triangle is is composed of TRIANGLE(60) and TRIANGLE(-60).
- dist <d> and theta<t> adjustments as shorthand for x <<d>*sin(<t>)> and y <<d>cos(<t>)>
- some simple parameterized rule form
