Procedural graphics generation in C

The demoscene is basically almost all about procedurally generated graphics and music - perhaps you could try entering your work at a demoparty competition. They don't much care about pretty code, but they do love pretty results. ;-)

I'm surprised there wasn't at least a brief mention of POV-Ray (povray). One of the first procedural graphics engines which is still active, and still used as an optional backend of Blender http://www.povray.org/

Very nice what you made. Where do you get your inspiration for the shapes?

Thanks for the mention of the fractalyze blog, Rexxar ! I am actually the owner of the blog, and I just would like to inform anybody interested in the subject to have a look at the XRVG Ruby library (I am the author), you may find it interesting. I actually went through a lot of different languages (from C++ to Clojure), and I am stuck now with Python and Javascript (You can have a look at the result at http://julienleonard.com if you wish). Thanks again, for the mention and the interesting thread !

or applesoft basic shapes.

the library allows to define and undefine the macros at any point so that you don't pollute your namespace too much. Without the macros, you would have to prefix all the commands, like SQUARE(n.X, 10, x.S, 0.5), etc...

Thumbs up on the initiative and result -- but why macros?

From the code samples it appears more that the author has created a DSL using C macros than providing a library. Such a bummer.

I think calling this "horrible" is pretty harsh. I wish programmers wouldn't be so eager to put down each other's code instead of taking the time to understand the reason why it is written that way. In this case, I think the library accomplishes its goal quite well: to provide a straightforward, logo-esque syntax for procedural drawing.

Code has different design constraints depending on where the code should run, how large the codebase is and what the project structure around the maintenance work is. Had this been a middleware component library and were there any reason for the routines to run in parallel threads I would have agreed.

Here, however I find your critique in bad taste and poorly thought out for code whose main value is the art generated by code, where brevity and simplicity of the code base is a value in itself.

There is no one true way to write code. Global state is not an evil in itself unless it causes hidden side-effects. For small single threaded programs a large global state can simplify things a lot.

It's like a lumberjack grumbles to an artisan wielding a penknife that it's far too small to cut down a tree.