I love procedural graphics... And game levels... And... Most spare time I spend generating graphics and music procedurally. The code isn't pretty (it's really iterating a lot of times and no time for refactoring...) but I guess we all should put it online like this :)

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/

I have done something similar in intent in c++ (but not released the code). Here are some results: https://www.flickr.com/photos/_rexxar_/

The owner the blog http://fractalyze.blogspot.com/ has probably also done something similar. He produce a lot of image, I found some of them inspiring.

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 !

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

Looks fun! I think you should document how to init / deinit, and what needs to be called for every main-loop iteration (just noctt_prog_iter? or something more?).

Turn that into an interpreted bytecode language, and you basically have invented PostScript.

or applesoft basic shapes.

Honestly, at a glance, the library design is horrible. A mix of C macros and global variables. The project is really small, to fix it all you need is a single struct pointer that gets passed to around.

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.

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...

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.

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.