Skip to content

ryg

Fabian Giesen: farbrausch coder, kkrunchy's author, compression programmer

ryg (Fabian Giesen) coded for the German demo group farbrausch from its first year. He wrote kkrunchy, the executable packer used for farbrausch's 64K intros from 2003 and by other groups including Fairlight and Conspiracy, and most of the 3D engine and mesh generator shared by Candytron, .kkrieger and debris. Since 2010 he has been at RAD Game Tools, working on the Oodle data compression library.

The readme of fr-08: .the .product, the 64K intro that won at The Party in December 2000, gives one of its six makers a deadpan job title: “Ryg [fg], compression technology supervisor”. Compression became Fabian Giesen’s speciality. Over the next few years he wrote kkrunchy, the executable packer that squeezed the group’s intros and was taken up by other groups too, and most of the engine behind .kkrieger and debris.. Then he took the same skills to a job writing compression software for the games industry.

Fast facts

  • Handle: ryg (credited in fr-08’s readme as “Ryg [fg]”).
  • Group: farbrausch.
  • Known for: kkrunchy; the texture generator, mesh generator and 3D engine shared by Candytron, .kkrieger and debris.; organising the Breakpoint demo party.
  • Studied: computer science at the University of Bonn.
  • Since 2010: RAD Game Tools, Kirkland, Washington, where he works on the Oodle compression library.

Compression technology supervisor

A 64K intro has to fit everything into 65,536 bytes: code, generated graphics, music, and the program that unpacks it all. fr-08‘s final version carries its packer’s credit in the file header: “rygs and torus’ exe packer”. That packer came before kkrunchy, which Giesen started in 2003. He later said that all of farbrausch’s “really serious 64k efforts were done with packers much worse than what you can use now. With a current version of kkrunchy, the original executable of fr-08 ends up below 48k.”

kkrunchy

kkrunchy is, in Giesen’s own words, “a small exe packer primarily meant for 64k intros”, and “relatively useless for anything else”. It was first used in farbrausch’s fr-030: Candytron, second in the PC 64K competition at Breakpoint 2003. Other groups took it up, including Fairlight, Rgba, Conspiracy and Equinox.

There are two versions. The first, written between 2003 and 2005, uses an LZ77 coder with an arithmetic-coding back end and a depacker of about 300 bytes of hand-written x86 code. The second, written roughly between 2006 and 2008, uses context mixing, an approach borrowed from the PAQ family of compressors. It predicts each bit from several statistical models at once and blends their guesses. The price was speed and size: its depacker is about 1.5K and unpacks only about 90 to 120 kilobytes a second, but it more than paid for itself. Recompressed with the new engine, .kkrieger shrank by more than 10K.

Giesen’s “secret ingredient” was a filter on the x86 code itself. Most executable packers only rewrite jump and call addresses so that they repeat more often. kkrunchy roughly disassembles the program and sorts the bytes of each instruction into separate streams by their job, such as opcodes, addressing bytes, jump offsets, displacements and immediate values. Values of one kind resemble each other far more than they resemble the bytes around them, so each stream compresses better on its own. He based this on the “split-stream” method in the PPMexe research paper. The filter also keeps a list of the 255 most recent call targets, so a repeat call to the same function costs one byte instead of four; he measured hit rates of 70 to 80 per cent.

.kkrieger and debris.

Giesen described Candytron, .kkrieger and debris. as sharing one codebase, and listed his part of it: “large parts of the texture generator, most of the mesh generation code, the 3D engine, the material/lighting systems (there are several), and the executable compressor used to pack them.” The .kkrieger readme credits him with the mesh generator, the 3D engine and kkrunchy, and the debris. credits name him and Chaos as its coders.

.kkrieger had to fit in 96K, and in late March 2004, less than two weeks before Breakpoint, it did not. Giesen later told the story on his blog. The compressed program had started at about 120K. Once the group had thrown out unused code and tightened the data formats, it was still about 102K, with content missing. Chaos pinned up a hand-drawn sign reading “98304”, the target in bytes. He and Giesen then wrote lekktor, a tool that ran the game once while recording which code was used, then deleted every path that never ran. It saved about 4.5K and got the game under the limit. It also threw away code that simply had not run during the recording, including part of the collision handling, and the released game has the bugs to show for it. Giesen called lekktor “one of the best bad ideas we ever had”.

He helped organise the parties where these productions were released. He was an organiser at Mekka & Symposium in 2001 and 2002, and has been on the Breakpoint organising team since the first Breakpoint in 2003, heading its competitions team from 2004.

Writing and released code

When farbrausch published its tools on GitHub in April 2012, Giesen was the contributor named on the most projects: GenThree, RG2, Werkkzeug3, the .kkrieger branch of Werkkzeug3, Altona and Werkkzeug4, the texture generator OpenKTG, lekktor and two versions of kkrunchy. He placed the kkrunchy code in the public domain. On his blog he wrote a series called “Debris: Opening the box” explaining how the tools worked.

His blog ranges well beyond the demo scene. His 13-part series “A trip through the Graphics Pipeline 2011” explains how graphics cards actually carry out Direct3D and OpenGL work. Some of his code has been taken up outside the scene. The public-domain stb_dxt.h, a small compressor for the DXT texture formats that graphics cards decode, is credited as “original by fabian “ryg” giesen”. In 2014 he published ryg_rans, a public-domain implementation of rANS, an entropy coder from Jarek Duda’s paper “Asymmetric numeral systems”.

RAD Game Tools and Oodle

Giesen joined RAD Game Tools in Kirkland, Washington, in 2010, and works on its Oodle data compression library, which game developers license to pack their data. In 2025 he described how crashes in the Oodle decoder, seen in Epic’s crash reports for Fortnite and from other Unreal Engine and Oodle licensees, turned out to come from a hardware fault in some Intel 13th and 14th generation desktop processors.

Sources

See also

Checked. Verified against primary sources and signed off by a person.