Codegolf motivation / process

This article is part of my series of article about my tiny graphics programs.

How i started : the demoscene

It all started with the demoscene which i know of since 2004 (probably from PureBasic french board, one the first programming language i learnt), PureBasic had some Amiga / Atari enthusiasts which were sharing sources of 80s/90s demo effects which is where i discovered the demoscene, i was mostly impressed with 64K programs as a teenager, most Farbraush productions, Conspiracy productions, Heaven Seven, Rise, TPOLM and Bypass productions, i was also impressed by demos on older platforms such as TBL, Future Crew, Sector One, Checkpoint, Holocaust, Equinox, TCB demos (mainly Atari ST because i bought an Atari STF at the time !) and other tiny prods such as Cdak (4Kb) or tube (256 bytes), also demos from groups such as ASD or MFX ones later on.

One of my first demo was done as a teenager with Pure Basic in June 2005, it had ripped tracks, it was never released and i just shared it with friends, it was probably my best effort to date of a full demo... :)

I was more of a regular follower / consumer although i always wished to participate, i then did several effects / 3D engine experiments (some of which on GP2X) but got bored very quickly with them, turns out doing demos require a lot of heavily focused interdisciplinary work (unless done as collaborative works), i still released a 1K intro POC in 2008 as a baby step which was the result of tinkering with some minimal OpenGL code and MIDI on Windows.

some 3D engine effects ~2012

I then had a short programming period on 8 bits system notably the Sega Master System (z80 assembly), i did a game (and another game prototype) and experimented with several effects for this platform (raster interrupt effects, colors cycling, chunky stuff) but mostly unreleased / prototypes, i never owned the system but i was attracted by its overall design which seemed more elegant (and easier) than the NES which i owned, i quite like the Master System VDP and the link with MSX computers architecture.

Also had a Sega Saturn period in which i learned some new quirks (first foray with RISC, Hitachi SH-2, delay slot, quads rendering...) with the goal of doing some demos or games, did some experiments in assembly / C but the complexity of the hardware and all its possibilities was overwhelming, this was probably a 'maximalism' period mixed with nostalgia where i thought this kind of hardware mess was cool.

I was still interested for a long time afterward by the quadrilaterals rendering of the Sega Saturn (also used by the Nvidia NV1 and in some other form by the Panasonic 3DO) which was pretty cool and a logical choice after sprite hardware albeit unpractical for the sort of 3D of that era, i attempted several times to replicate the algorithm only to be really successful later on after joining the ideas of a floor-casting prototype and a tiny integers only 3D cube software renderer, the result is a simple but tiny forward textures mapper / quads renderer.

some Sega Saturn 3D stuff ~ mid 2008 / 2009 and perhaps later

Around ~2008 i started being focused on 1K and 256 bytes and smaller graphics programs, these extremely small binaries felt like magic.

What is the appeal about very small graphics programs ? They are a bit arcane at first so intriguing from a technical point of view and generally focus on a single effect so they are quite manageable to do by a single person with scattered focus, they are also a fun exercise to discover platforms, another appeal to me is that they often use "forgotten" display hacks and most productions deploy these tricks within a completely barren graphics environment close to the hardware similar to the early days of computing of which i have a special interest.

The constrain imposed by code golfing is also a fun and educative way to explore / understand algorithms by playing around their core concept in a creative way and without being too scattered.

Around ~2018 i started doing regular computer graphics experiments of all kinds in a Processing environment, i realized at some point that some of my experiments were very small algorithmically and could perhaps fit in 256 bytes.

Then i started by looking at the possibility of doing small programs on Linux to prove my point and tried to port some of my earlier experiments, first in C then with x86 / x64 assembly, doing it in C was because i was more accustomed to it and because i took it as a challenge to do something tiny and interesting in C on Linux.

I released my first 512 bytes in 2020, i wanted it to be 256 bytes but the compiler output kinda told me that it was not possible without going full assembly, this idea didn't satisfy me at that point so i just released it as a 512 bytes followed by my first 256 bytes later on with a small C framework i was iterating on at the same time, i then tinkered with assembly which allowed me to port some more experiments.

Although the demoscene is a very competitive subculture i was never interested in the competitive aspect (sparingly accept challenges though !), i am more attracted to its creative content; the creativity / trickery peoples deploy under constraints with the pleasing visuals that feels like magic and sometimes by the overall aspect of some productions such as Live Evil with a combination of visuals and sounds that feels like psychedelics to my sensors (note : i don't use any !), i also love the puzzle aspect of optimizing programs for size and discovering forgotten / new tricks.

There is also something interesting to me with small programs in term of elegance, low energy expenditure (efficiency) and easiness to share and replicate the contained information.

About NFTs

Rules

Process

What i like about the TIC-80 platform is the severe graphics restrictions in term of resolution and colors but associated with modern languages (JavaScript, LUA etc.) and easy graphics API, it is a very sympathetic framework to code for without hassle and with graphics restrictions similar to early 8 bits computers without the oddities. I'd actually love a simple similar hardware platform with 60s / 70s / 80s tech but without the oddities of all the existing legacy hardware (= way more restricted but using modern ideas), i'd like easy repairability as well or one which could be built or hacked from scratch perhaps even from salvaging or old tech such as magnetic-core memory.

RISC OS / Acorn platforms is my go-to for late 80s up to now graphics code golfing, i love programming for the early Acorn hardware (mainly due to the early ARM CPU / RISC architecture) and i love that my programs still works in 2023 on modern hardware based on ARM CPU such as Raspberry PI.

The only issue with code golfing on this platform is that early ARM has bigger code density than x86 mainly due to 4 bytes cost per instruction but it is also what makes it cool and there is workarounds (CodePressor), there is also some oddities as well such as aligned writes but it also has many advantages due to its RISC nature. It is a great alternative to the commonly used DOS platform for demoscene codegolf, DOS always has an edge though due to its very short graphics setup with old modes such as mode 13h whereas the RISC OS setup would take about as much bytes as x86 + Linux fbdev platform unless some shortcuts is taken. (staying at desktop resolution, no double buffering, no vsync etc)

Linux / x86 is my main system since ~2010 and it is my go-to for modern graphics code golfing.

A fairly complete guide for code golfing on Linux is available here.

On Linux i am writing programs in x86 assembly language nowadays with a custom ELF header and i am using the Linux framebuffer device (fbdev) which still works on modern Linux distributions (it has generic support since ~1997 in the kernel), the API is quite minimal and require two syscall to be able to output some pixels on the screen so the end setup is fairly small and it works for high resolutions and color depth.

I tend to use SIMD instructions which helped on saturation arithmetic early on, nowadays i also use it to pack multiple operations as a single instruction or for floating-point arithmetic, this has a slight impact on the programs compatibility.

Linux productions still have high binary size cost (even more so if you output any sounds) compared to some platforms such as DOS due to the ELF header (too bad that A.out was flushed out from the kernel in ~1995, it is tinyer than ELF) so if you takes into account the framebuffer API and the header you already have about 70 bytes taken out of your binary which is already more than 1/4 of a 256 bytes target, you also have to handle packed RGBA format if you go for modern color depth.

Due to the ELF header targeting DOS may be better sometimes when these 70 bytes are needed (COM file has about no headers and graphics setup is small), there is not much differences with x86 Linux although it is a bit trickier with all the available display modes and compatibility issues, using AVX instructions may also require additional setup code but going for common low resolution modes and SSE works out of the box, high resolution on DOS (VESA) can be tricky with a lot of compatibility issues as well but it can be done with ~20 bytes setup with some shortcuts.