andrewf
Joined 19 years ago
Joined 19 years ago
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.
I could still read the text! And it's useful to read texts and understand 95%, or 80%, or even 50%! IMO "fully understand what you're reading" versus "can't understand what you're reading" is a harmfully discouraging dichotomy. You can often gloss over such things rather than struggle with them.
EDIT: I recall reading that the Netflix client can continuously select between multiple content caches. I'm guessing they do this because it's a quality-of-service and capacity win over making a "best guess" at the start of a session, and sticking with it. It should also enable transparent recovery from a broken or slow cache node. If you test in a busy place with multiple caches, the loss of one needn't be a big deal.
I'm guessing dBase was itself built using Microsoft's compilers, so pulling in other code from the same compiler was plausible. Not a product choice re: the Turbo compilers, just a disjoint path dependency between two acquired product lines (Ashton-Tate's dBase, and Wizard C).
This is the reason that Clipper, a third-party dBase compiler, could only link against .OBJs from particular versions of Microsoft C. Clipper compiles to p-code whose interpreter is implemented in Microsoft C; "linking" a Clipper program is actually linking a Microsoft C program with a static array comprising the Clipper compiler's output. So you can mix in a .OBJ expecting that version of the Microsoft C runtime library. Not a .OBJ expecting the Turbo C++ runtime library.
Sometimes a "punch in the face" is useful. Makes you re-evaluate things. Being punched in the face all day, every day, is just tiring.
"Six paediatric health-care professionals were recruited to swallow a Lego head."