4 Years of Ludicon

# Four years of Ludicon Source: [https://www.ludicon.com/castano/blog/2026/10/4-years-of-ludicon/](https://www.ludicon.com/castano/blog/2026/10/4-years-of-ludicon/) Last weekend marked the four\-year anniversary of Ludicon\. I started Ludicon because I believed that working independently would let me do my best work\. Building software on my own, I can move fast, take risks, and focus on problems others don’t consider practical, or slow down and go deep into rabbit holes without having to justify myself\. I’m happy with the quality of the work I’ve produced, excited about what is yet to come, but disappointed with its commercial success so far\. In retrospect, 2022 was not a particularly good time to start a game middleware business\. In that year alone the game industry saw 8,500 layoffs\. That trend would continue getting worse and has not stopped yet\. Middleware was already in a steady decline\. Unity, Unreal and others offered complete engines with no upfront costs\. The question was no longer whether a third\-party component was better than what you’d write yourself, but whether it was better enough to justify replacing what the engine already provides\. It rarely was\. Epic’s acquisition of RAD in 2021 marked the end of that era: the last major independent vendor of core runtime technology was now part of an engine\. By the time I started working on Spark in 2022, engine consolidation had won\. Against that backdrop, the business case was ambiguous, but my hope was that with reduced headcounts, long\-term research into core technology would slow down and outsourcing that technology would become more attractive\. When I started working on Ludicon I believed that there would be a growing market for texture compression\. Games were only getting larger, fidelity targets kept increasing, and textures were often the assets with the largest footprint\. At the same time, an increasing amount of content was generated by players themselves\. This created an explosion of content, and with it the need to compress at runtime\. What I did not anticipate was AI\. Generative tools lower the barriers to content creation\. At the same time, the AI buildout has created shortages and driven up the price of memory and storage\. Existing devices are staying in use longer, and new devices often ship with less memory than they did a few years ago\. Both pressures push in the same direction: more content, less room for it\. Over the last year AI has also changed the software industry\. This transformation has been so fast that it induced vertigo\. At some point, I wondered if my job would be at risk\. Could LLMs produce competitive texture codecs on their own? I tried and they were nowhere close\. To produce good results it needs expert human input and judgement\. Still, AI has transformed the way I code, but not the way you would expect\. For the most part I still write the codecs by hand, the old fashioned way\. AI just lets me do that more efficiently\. AI reviews my changes and it routinely catches bugs that would have taken hours to debug\. It has allowed me to build tools that feel like having superpowers\. For example, I can edit one shader and automatically display statistics and annotated assembly listings on all the platforms that I support\. When a customer reports a bug or issue, I just plug in the relevant device and let an agent build a repro and suggest a fix for the problem\. When a CI build fails, an agent automatically fixes it and opens a PR\. The validation, CI, and regression testing tools I have today are better than what I would have imagined possible as a solo developer\. This has allowed me to stay focused on the problems that I enjoy working on and where I can make a difference\. *Screenshot of the the Spark assembly viewer in action* After Epic’s acquisition of RAD I though there would be a need for an independent technology provider, and I hoped I could fill that vacuum\. Filling it with another rate\-distortion optimized \(RDO\) encoder meant competing with an established product built by some of the brightest developers I know\. I had written RDO encoders before and I concluded it was a race I could not win on quality or performance\. In all likelihood I would be forced to compete on price\. Real\-time compression was more interesting\. It solved the problem of content created at runtime, and it opened a different solution space for storage and transmission\. Traditional RDO block encoders are constrained by the fixed\-rate block structure and do not scale to low bitrates\. With real\-time compression, the intermediate representation can be anything, as long as it can be encoded into a GPU\-friendly format at load time\. I still think this is the right direction\. Modern image formats like WebP and AVIF, combined with Spark, already deliver much better compression ratios than RDO block encoders\. However, they suffer from slow decompression performance\. In the next year or so I predict there will be new codecs with competitive quality and much higher decoding throughput\. The recent work on neural textures and learned codecs will widen the space further\. Four years in, and I think my bet looks better than it did in 2022\. ## Post navigation