Codegolf motivation / process

Many of my programs fall into the "procedural graphics" category of the demoscene, generating non-animated visuals. This is partly due to personal preference and partly because I find much greater creative freedom in the algorithms i can use, even though it might initially seem less exciting to viewers.

Procedural graphics programs seems to be a "recent" category for the demoscene as it show that in early 2000 most if not all of the demoscene releases were programs with animated graphics, procedural graphics programs came out slowly afterward (graphics compo always existed in parties though but this was not just independent programs), it is rather funny to see all the peoples confused by the lack of animation at these time because they expected what the demoscene 'originated from' and improved upon (cracktro then independent impressive "in your face" animated programs), i personally find that procedural graphics close the time loop as cracktro began as non animated programs in early 80s just showing some logo and few other elements, there is also other non animated programs art stuff at this period perhaps motivated by BASIC.

My "theory" on the rise of procedural graphics is that it has to do with the rise of tiny programs (especially 4k and less where non real-time is perhaps easier at first) and much less relevance on the optimization part of real-time demos (due to all the compute ?) so code peoples started to find other challenges and tiny programs had a challenge in term of binary size, the programmable graphics pipeline may also be relevant in the rise of procedural graphics.

Shrinking my programs was a way to regain control in a different way through different value encoding, it oppose and transcend the NFT market entirely in its principle.

Not opposed to AI at all, i see huge potential mainly because the huge data processing can be seen as an efficient compression of our collective intelligence with the ability to poke around it, i remain neutral however due to potential future concerns, it has high requirements (computational, storage) unavailable to me and thus doesn't interest me beyond curiosity, it is also bad at low-level graphics code golfing and i am fairly certain it will still struggle with this for some time.

• i only do graphics code golfing; tiny code that will produce something to the screen (static or animated) with small code
• tend to not use APIs much (with the exception of mandatory stuff) and prefer software rendering / do everything as close to the hardware as possible
• i prefer assembly or languages that allow close to the hardware code / executable such as C (not much interested in high level languages code golf or VM stuff with the exception of fantasy computers), the goal is optimizing for binary size instead of optimizing for source code size, this distinction leads to different result
  

My code golfing process starts by prototyping graphics experiments in a high level environment first such as p5js (i also port it to C sometimes), trying to make something i am satisfied with, once i have the base algorithm i tend to tweak the code (parameters etc.) blindly without too much thinking and just seeing the end result, i find it relaxing, interesting stuff may emerge sometimes and with enough tinkering i roughly know what works and what is going on on the screen so i can direct the process. Also tend to roughly guess the size of the binary once it will be optimized, this also help the direction.

There is also some intros where i had a rough idea of what i wanted to do, most ideas come from other peoples (design, algorithm etc.), i also use the Twitter platform heavily since there is many interesting stuff coming from other art scenes such as generative ones. (Processing etc.)

Once i have a working code i am satisfied with i tidy the code and optimize it as much as i can with a focus on the target platform : reducing expressions, simplifying, using bit-wise operations, doing structural change etc. there is several tools that can help such as Wolfram Alpha or Godbolt or even AI powered tools (Chat GPT ?).

The low level optimization phase sometimes require multiple tries to get something that may be worth and in some rare cases i may have to cut features, if i do there is a high probability that i will ditch the code momentarily to think about it later and accumulate new tricks or ideas.

I sorta heavily use the Minsky circle algorithm to draw interesting stuff (approximation for sin/cos but not only...), i tweaked the parameters for a long time so i have a big pool of sketches that i can start with, most of them shrinkable to 256 bytes i believe.

My advice for someone who want to start is to prototype a lot, approach different ideas (fractals, affine transforms etc.) or rendering methods and try to shrink them and make some sort of tiny tricks bag that you can peek from, deciphering other programs is also a quick way to gain skills and old sources such as SIGGRAPH papers can lead to ideas, although not my first choice you can also go social, going to parties or looking for online resources or community Discord.