I've a retrocomputing project which has been gathering dust since before I used an LLM. The idea is to render an isometric view with Quake-style lightmaps; if s

I've a retrocomputing project which has been gathering dust since before I used an LLM. The idea is to render an isometric view with Quake-style lightmaps; if scrolling is slow enough I only need to render a small slice of the screen each time. I got as far as a proof of concept on a simulated 286 which indicates the pixels-per-second I can achieve is fast enough. Testing on a real 286 would be the next step. All the assembly code, and the C harness which loads the textures etc, was hand done by me, and period correct. That's where the fun is! Outside of that, there are so many anachronisms. I actually built the test geometry as a quake map, and processed it using Quake's BSP/lightmap tools. That's 1996 vintage.. except I'm using a newer Quake editor (Trenchbroom, 2013) and modern forks of the tools. All natively on a modern system with a 4K monitor. Building and non-performance testing of the DOS code happens in a Windows XP (2001) VirtualBox (2007) using its' Shared Folder feature. I might have time to pick this up again soon. My post-processing of the Quake .bsp presently only handles axis-aligned 64x64 surfaces with some hardcoded texturing assumptions. I'll want a full .bsp-to-isometric-data "renderer" - either written from scratch or somehow derived from Quake's source. But this is all just to enable the 286 assembly code noodling, which is what I want to spend time on! So I'll probably use Claude to assist with the tooling side. By "assist" I mean "do as much as possible to produce the file format I specify". It doesn't seem much worse to me than all the other modernisms I'm already relying on outside of the core task.