Coverdisc

Retro PC gaming, the mod scene and keeping old files alive

  • The rise and quiet decline of the level editor as a shipped feature

    The rise and quiet decline of the level editor as a shipped feature

    There was a period when buying a PC game frequently meant getting the editor that built it. Not a simplified toy version, but in many cases the actual tool the development team used, with its inconsistent interface and undocumented behaviour intact.

    It was a remarkable arrangement, and it did not last. Understanding why it happened, and why it stopped, says a lot about how PC development changed.

    Why it made sense at the time

    The commercial argument was straightforward. User-made levels extended a game’s life, which supported its price at retail and its presence on shelves. A game with an active editing community stayed in conversation and stayed stocked.

    The engineering cost was also low, because the editor already existed. It had to exist: someone built the levels. Shipping it meant copying it onto the disc and writing some documentation, rather than developing a separate product.

    Low cost was doing a lot of work in that calculation, and it is exactly the part that changed.

    Content pipelines grew up, and grew complicated

    An early editor worked on files the engine loaded directly. Place geometry, save, run the level. There was a build step for spatial data, but it was a single tool run.

    As engines matured, the pipeline between editing something and seeing it in the game acquired stages: lighting to precompute, visibility to calculate, geometry to optimise, assets to convert into engine-specific formats. Each stage had its own tool, its own configuration and its own failure modes.

    Shipping an editor now meant shipping a toolchain, and supporting a toolchain is a different proposition to supporting a single application. Every problem a user hit anywhere in that chain arrived as a support request about the game.

    The tools stopped being separable

    Editors also became entangled with the studio’s own infrastructure. Version control integration, asset databases, internal build servers, licensed middleware with its own redistribution terms. Extracting a shippable version from that meant deliberately building one, at real cost.

    The middleware point is underrated. A studio licensing a third-party renderer, physics library or animation system could not necessarily redistribute the editing components at all. The terms permitted shipping a game, not the means of making one.

    What replaced it

    The shipped editor did not vanish so much as split in two directions.

    At one end, some studios built genuinely public toolsets, documented and maintained as products in their own right, with the modding community treated as a constituency rather than a side effect. This is more work than the old arrangement and produces better results when a studio commits to it.

    At the other end, engines themselves became available to everyone. If the same engine that built a commercial game can be downloaded and used directly, the argument for shipping a game-specific editor weakens considerably. Someone who wants to build levels can build a whole game instead.

    • Games shipping full editors clustered in the period when the editor was a single tool over engine-native files.
    • The decline tracks pipeline complexity more closely than it tracks any change in player interest.
    • Middleware licensing quietly removed the option for a category of games entirely.

    What was lost in the middle

    The thing the old arrangement did well was accident. Someone bought a game, found an editor on the disc, opened it out of curiosity and discovered they liked building things. That path required no decision and no download; the tool was simply there.

    The modern equivalent asks for a deliberate step: find the engine, install it, work out where to start. That is a much better ceiling and a much higher floor. The people who cross it can do far more than any shipped editor allowed. The people who would only ever have crossed it by accident mostly do not.

    Both arrangements produced good work. They did not produce it from the same people.

  • Link rot in games writing: what happens when the sources disappear

    Link rot in games writing: what happens when the sources disappear

    Read enough writing about games from the 1990s and a pattern appears. A claim is made, sourced to an interview. The interview is cited to a website. The website has been gone for fifteen years. The claim continues to circulate, now unsupported by anything anyone can check.

    This is not unique to games writing, but games writing has it badly, because so much of the primary material was published on independent sites, forums and fan pages rather than in anything with an institutional commitment to staying online.

    How the decay actually happens

    Outright disappearance is the obvious case, and not the most common one. Several quieter failures do more damage because they are harder to notice.

    • The domain lapses and is re-registered by someone unrelated. The URL still resolves, now to different content entirely.
    • The site migrates to new software and every URL changes. The content exists; every link to it is broken.
    • The page survives but the thing it embedded, a video or a forum quote, does not.
    • The forum thread is intact but only for logged-in members, invisible to anyone following a citation.

    The second is the most frustrating for research, because the material is right there and simply unreachable by the route everyone used to cite. A platform migration can break every inbound link to a site’s entire archive in a single afternoon.

    Archives help, but not evenly

    Web archiving has saved a great deal of this material, and anyone researching this era should reach for it early. It is also patchy in ways worth understanding rather than being surprised by.

    Coverage depends on whether a crawler found the page, how often it revisited, and whether the site permitted crawling at the time. A site that excluded crawlers during its active life may have no useful archive at all, even though it was widely read.

    Dynamic content is captured poorly. Anything assembled by scripts after the page loads, anything behind a form, and most search results are usually absent. Forum archives in particular tend to preserve the first page of a thread and nothing after it.

    Media is the weakest area. Text survives well, images less so, and audio and video frequently not at all. An interview published as a video is far more likely to be lost than the same interview published as text.

    What this means for writing about old games

    The practical upshot is that a citation to a dead link is not a citation. It is a note that a citation once existed. Treating it as verification is how unsupported claims harden into consensus.

    A few habits make a real difference, none of them onerous.

    • When citing a live page, also record an archived snapshot. It costs seconds now and preserves the citation permanently.
    • Quote the relevant passage rather than only linking to it. A quotation survives the page it came from.
    • Record the date you accessed something. It tells a later reader which snapshot to look for.
    • State when a claim comes from memory or from an unverifiable source. That is honest and useful, whereas presenting it as sourced is neither.

    The uncomfortable part

    Some of what is widely believed about this era cannot be checked any more. The person who said it may still be around, but the specific claim, in its specific wording, exists now only as repetition.

    The correct response is not to discard those claims, many of which are probably true. It is to be clear about their status. There is a real difference between something documented and something everyone remembers hearing, and collapsing the two is how folklore ends up presented as history.

    Writing about a period whose primary sources are actively disappearing means accepting that some questions now have no verifiable answer. Saying so is more useful than filling the gap with confident guesswork.

  • Getting old PC games to run at sensible resolutions on a modern display

    Getting old PC games to run at sensible resolutions on a modern display

    Running a game written for a 4:3 cathode ray tube on a modern widescreen panel goes wrong in several distinct ways. They get discussed as one problem, which makes them harder to fix than they need to be. Separating them is most of the work.

    Problem one: the aspect ratio the game assumed

    A game targeting 320×240 or 640×480 assumed a display roughly four units wide to three units tall. Stretch that image across a 16:9 panel and everything becomes wider than intended. Circles become ellipses and characters look heavier.

    Some players do not notice or do not mind. Others find it intolerable once seen. Either way it is a display decision, not a game one, and the fix is usually in the graphics driver or the display’s own settings rather than anywhere in the game.

    Complicating this, a handful of modes from the period were not square-pixel modes at all. The 320×200 mode common in earlier titles was displayed at 4:3, meaning pixels were taller than they were wide. Rendering it at exactly 320×200 on a square-pixel display is arguably wrong, even though it matches the framebuffer precisely. Both choices have defenders.

    Problem two: how the small image gets enlarged

    A 640×480 image on a 2560×1440 panel has to be enlarged. How it is enlarged matters enormously and is often the difference between a game looking crisp and looking like a smeared photograph.

    • Nearest-neighbour scaling keeps hard pixel edges. It looks sharp, and blocky where the original art was blocky.
    • Bilinear filtering smooths between pixels. It softens edges and, on pixel art, tends to look like a blurred photograph.
    • Integer scaling multiplies by whole numbers only, avoiding uneven pixel sizes at the cost of black borders.

    Uneven scaling is the specific culprit behind an effect people often struggle to describe: some pixels appear larger than others in a way that shimmers during movement. It happens whenever the scale factor is not a whole number, and integer scaling eliminates it outright.

    Problem three: the render path

    Games from this period might use software rendering, an early hardware API, or a proprietary interface for a specific graphics card. These have very different prospects on current hardware.

    Software renderers generally age best. They ask nothing of the graphics hardware beyond somewhere to put the finished image, so they still work. They are also usually the mode with the fewest surprises, and on a fast machine the performance cost is irrelevant.

    Early hardware paths are less reliable, because they depend on driver behaviour that has been reimplemented several times since. A game may run, may run with visual faults, or may fail on startup. Wrapper layers that translate old calls into current ones fix a good share of these cases.

    Proprietary paths targeting a specific vendor’s hardware need emulation of that interface. Where such a layer exists, results are often excellent, since these paths were frequently the game’s best-looking mode.

    Problem four: the game’s own limits

    Some games simply cannot render above a certain resolution. The interface is drawn at fixed coordinates, or the field of view is computed in a way that assumes a particular shape, or the menu is a bitmap of a specific size.

    Forcing a higher resolution on these produces interfaces anchored to the wrong corner, text off the edge of the screen, or a field of view that crops the top and bottom rather than widening the view. That last one is worth checking deliberately, because a widescreen mode that removes information rather than adding it is a downgrade dressed as an improvement.

    A workable order to attack it in

    Start with the game’s own options at its native aspect ratio and confirm it runs correctly at all. Then set the display or driver to preserve aspect ratio rather than stretch. Then choose a scaling method, preferring integer scaling where the game’s resolution allows it. Only then consider a resolution patch or widescreen fix, and test whether it widens the view or crops it.

    Working in that order means each change is tested against a known state. Changing four things at once and finding the result unsatisfactory tells you nothing about which of them was responsible, and that is how an evening disappears.

  • The total conversion problem: when a mod stops needing the original game

    The total conversion problem: when a mod stops needing the original game

    A total conversion replaces a game’s art, sound, levels and often its rules, keeping only the engine. The result plays as a different game entirely. The genre produced some of the most ambitious amateur work of the period, and also some of the most fragile.

    The fragility is worth examining, because it explains why so many of these projects are difficult to run now, and why some vanished completely while their more modest contemporaries survived.

    The dependency that never went away

    However complete a total conversion was, it still needed the original game installed. The engine executable was the one thing that could not be replaced, because it was the commercial product being modified rather than data being loaded by it.

    For most of the 1990s this was a reasonable expectation. The base games were popular and widely owned. A project could assume its audience already had a copy, and distribute only the replacement content.

    The assumption aged badly. Two decades on, the modification is downloadable and the game it needs may not be, or may be available only in a rereleased form with a different file layout, a different executable and different behaviour. The mod survived; its host did not survive unchanged.

    Version pinning made it worse

    Engines changed across patches. A conversion built against one point release frequently misbehaved on another, because it depended on specifics of how that build handled a particular entity, sound or rendering path.

    Readme files from the era are full of instructions to install a specific patch level and no higher. Those instructions were sound advice at the time and are close to unusable now, because the patch in question was distributed from a publisher’s server that stopped existing years ago.

    • Check whether a source port supports the conversion directly. Many ports have absorbed compatibility handling for well-known projects.
    • Read the original documentation before assuming a failure is a bug. A large share of problems are the documented version requirement, unmet.
    • Note which files the conversion actually replaces. Where it only replaces data, options are broader than where it also ships a modified executable.

    The distribution problem

    Total conversions were large by the standards of the connections available. A project could run to tens or hundreds of megabytes at a time when that was an overnight download. Distribution therefore concentrated on a handful of hosts, mirrors and cover discs.

    Concentration is efficient and fragile in equal measure. When a host closed, everything it uniquely held went with it. Projects that were mirrored widely survived; projects that lived on one enthusiast’s server generally did not, regardless of quality.

    This is a genuinely poor filter for what should have been preserved. Survival correlates with how well-connected the team was, not with how good the work was.

    Modified executables and the legal grey

    Some conversions went further and shipped patched executables, either to change engine behaviour or to remove the dependency on the original data files. This solved the installation problem and created a distribution problem, because the result contained modified commercial code.

    Projects in that position tended to be circulated quietly, which is precisely the opposite of what preservation requires. The more self-contained a conversion was, the less openly it could be shared.

    The situation improved substantially where engines were later released under free licences. A conversion could then target a legitimately redistributable engine, and several long-running projects made exactly that migration. Where no such release happened, the original constraints still apply.

    What made a conversion durable

    Looking across the projects that are still straightforwardly playable, the pattern is consistent and unglamorous. They kept content and engine strictly separate. They documented their requirements precisely. They were mirrored in more than one place. They targeted an engine that later became freely available.

    None of that has anything to do with the quality of the design, the writing or the art. Durability was a distribution and architecture property, decided early, usually without anyone thinking of it as a preservation decision at all.

    That is a useful lesson for anyone building on someone else’s engine today. The work that survives is the work that can be moved.

  • What is actually inside a WAD file

    What is actually inside a WAD file

    The WAD is one of the most consequential file formats in PC gaming, and one of the simplest. Understanding its structure explains a surprising amount about why the modding culture around it developed the way it did.

    The name is usually expanded as Where’s All the Data. That expansion appears in the original technical documentation, so it is at least contemporaneous rather than a later joke, though the format’s design suggests the acronym came second.

    Three parts and nothing else

    A WAD file has a twelve-byte header, a body of raw data, and a directory. That is the entire format.

    The header records an identification string, the number of entries, and the byte offset where the directory begins. The identification string is either IWAD or PWAD. An IWAD is a base game file, self-sufficient and containing everything needed to run. A PWAD is a patch file, containing only entries that should replace their equivalents in the loaded IWAD.

    That distinction is the foundation of the entire modding scene. The engine loads the base file, then loads any patch files over it, and later entries with the same name win. No installer, no file replacement, no risk to the original. Users could try a modification and remove it by not loading it next time.

    The directory is a flat list

    Each directory entry is sixteen bytes: a four-byte offset, a four-byte size, and an eight-byte name padded with nulls. There is no type field, no timestamp, no folder structure and no compression.

    Two consequences follow immediately. Names are limited to eight characters, which is why entries carry terse names like E1M1 or PLAYPAL rather than anything descriptive. And because there are no directories, organisation had to be expressed through naming conventions instead.

    The convention that emerged used marker entries: zero-length entries whose only purpose was to bracket a range. Everything between the sprite start and sprite end markers is a sprite. Everything between the flat markers is a floor or ceiling texture. The engine determines type by position relative to markers, not by anything recorded in the entry itself.

    Why a level is many entries rather than one

    A level is not stored as a single blob. It is a marker entry naming the level, followed by a fixed sequence of entries in a required order, each holding one aspect of the level’s geometry and contents.

    • THINGS lists every object placement: monsters, items, player starts.
    • LINEDEFS and SIDEDEFS describe walls, their textures and their behaviours.
    • VERTEXES holds the raw coordinates those lines connect.
    • SECTORS defines floor and ceiling heights, lighting and special behaviour.
    • SEGS, SSECTORS and NODES hold the precomputed spatial subdivision the renderer walks.

    The last group matters more than it looks. Those entries are generated by a separate tool from the level geometry, and the engine relies on them being correct for rendering and collision. An editor that changed geometry without regenerating them produced a level that looked right in the editor and behaved incorrectly in play.

    This is why the node builder was a distinct, named piece of software in the toolchain rather than a hidden implementation detail, and why the quality of a node builder was something modders held opinions about.

    What the format got right

    The design was not obviously destined to spawn decades of modification, but three properties made it happen.

    Replacement by name meant a modification only needed to include what it changed. A file altering one texture could be a few kilobytes. Distribution over a modem was practical.

    The absence of compression meant the format was trivially inspectable. Anyone who could read a hex dump could work out the structure without documentation, and people did, quickly, before any official specification was published.

    And the separation of patch from base meant the base file was never modified. The barrier to experimenting was near zero, because nothing could be broken permanently.

    Reading one today

    The format is simple enough to parse in a short script: read twelve bytes, seek to the directory offset, read sixteen bytes per entry. Modern tooling exists and is better than writing your own, but the exercise is genuinely instructive, because the structure is small enough to hold in your head entirely.

    Very few formats from the period are that approachable. Most of what came later was compressed, packed and versioned in ways that require documentation to make sense of. The WAD can be understood by staring at it, and a great deal of what followed in PC modding came from that fact.

  • Why so many late-90s PC games shipped with a separate installer disc

    Why so many late-90s PC games shipped with a separate installer disc

    Pull a boxed PC game off the shelf from around 1998 and there is a decent chance it holds more than one disc. The instinctive explanation is that the game was simply too big for one CD. Sometimes that was true. More often it was not, and the real reasons are more interesting than raw capacity.

    A CD-ROM held about 650 megabytes. A hard drive of the same period might offer two to six gigabytes in total, shared with the operating system and everything else the machine did. That mismatch, rather than the size of the game itself, shaped how releases were put together.

    Reading from disc was slow, and installing everything was not an option

    A 4x drive managed roughly 600 kilobytes per second on a good day, with seek times measured in hundreds of milliseconds. Streaming full-motion video or a large audio track off that disc during play was possible but fragile. Any stutter was immediately audible.

    Publishers responded by splitting content by access pattern rather than by size. Assets needed constantly went on the hard drive during installation. Assets needed occasionally, particularly cutscenes and music, stayed on the disc and streamed. A second disc was frequently just the video and audio that nobody wanted to spend 400 megabytes of precious drive space on.

    This is why installation size options mattered so much. Minimum, typical and full installs were not marketing choices. They were the difference between a game that ran and a game that would not fit.

    Copy protection wanted a disc in the drive

    Through this period the standard anti-piracy measure was a disc check. The game confirmed that a particular disc was present, sometimes by reading a deliberately malformed sector that ordinary duplication software would not reproduce faithfully.

    If the check demanded a disc anyway, there was no benefit to compressing everything onto one. A design that kept audio and video on disc two, then asked for disc two during the cutscene, achieved both goals at once. The player would have needed to swap discs regardless.

    Duplication economics rewarded more discs, not fewer

    Pressing CDs at volume was cheap, and got cheaper with quantity. The marginal cost of a second disc in an already-manufactured box was small compared with the engineering cost of squeezing content into one. Faced with a choice between weeks of asset compression work and adding a disc that cost pennies, publishers added the disc.

    There was also a presentation argument. A box with three discs looked substantial on a shelf next to a box with one. Whether that shifted units is hard to establish now, but the belief that it did was widespread enough to be repeated in interviews from the period.

    The awkward legacy for anyone installing these games today

    Two habits from that era create most of the problems now. The first is the hard-coded drive letter. Installers that recorded the CD drive as D: still expect D:, and a modern machine with a virtual drive mounted elsewhere will fail a check that has nothing to do with the disc itself.

    The second is the split install itself. Copy the contents of every disc into one folder and many of these games run perfectly, because the code looks for files by relative path and no longer cares which physical disc they came from. Where that fails, it usually fails on the protection check rather than on the assets.

    • Check whether the game reads a configuration file recording the install path and drive letter. Editing it is often quicker than reinstalling.
    • Copy all discs into a single directory before troubleshooting anything else. It resolves a surprising share of missing-file errors.
    • Expect audio to be the awkward part. Redbook audio tracks are not files on the disc and do not survive a naive copy.

    That last point catches people out repeatedly. A game using Redbook audio played music by asking the drive to play an audio track directly, the same way a CD player would. Copying the data track gets the game; it does not get the soundtrack. Extracting those tracks to a supported format and pointing the game at them is a separate job, and one worth knowing about before concluding that a copy is broken.

    What the multi-disc era actually tells us

    The shape of these releases was set by constraints that vanished within a few years. Drives got faster, hard drives got enormous, and broadband made physical distribution optional. What remains is a body of software with assumptions baked in about where things live and how fast they can be read.

    Understanding those assumptions is most of the work in getting one of these games running today. The problem is rarely that the game is old. It is that the game is confidently expecting a world that no longer exists.