Coverdisc

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

  • Recovering a collection that has been wet

    Water reaching a stack of boxed media is a bad morning, and the instinct is to work fast on the discs. Speed is right. The priority is wrong. Most of what gets lost after a flood is lost in the weeks afterwards, in the room rather than on the shelf.

    The room is the problem that outlasts the salvage

    Start with this, because the salvage guides leave it out. The collection is usually recoverable. The room is what keeps costing.

    Once a floor void or a plaster wall has been soaked, it holds water for weeks after any surface feels dry, and what grows next is in the building itself rather than on your items. That is the point at which a mould removal company in Dallas, or wherever you happen to be, is the sensible call: they measure moisture inside the structure and treat what is behind the plaster, which no amount of airing out a room achieves.

    Putting a dried collection back into a room that is still wet is how people lose the same material twice.

    Triage by material, in this order

    Paper first, always. Manuals, inlays, boxed documentation and printed sleeves are the only genuinely time-critical part of a collection, because paper left wet bonds to itself as it dries and cannot be separated afterwards.

    Magnetic tape next. Cassettes and open reels tolerate water surprisingly well in the short term and badly over a fortnight. Get the shells open and the tape out of standing water.

    Optical discs are the least urgent. The data layer is sealed, and the usual damage is to the printed label and to a paper sleeve stuck against the surface.

    Floppy media is a judgement call. A submerged disk is often readable once the jacket is cut away and the cookie rinsed in clean water and dried flat, which sounds like vandalism and is standard practice.

    Separate, interleave, and do not use heat

    Stand things up, fan them out, keep air moving with a fan rather than a heater. Interleave wet paper with dry kitchen roll and change it as it takes up water.

    Heat is the commonest mistake. A hairdryer or a radiator dries the outside of a sleeve and drives moisture into whatever sits under it, and on tape it distorts the backing permanently. Cool moving air, for days if necessary.

    Freeze whatever you cannot reach within about forty-eight hours. Paper in a freezer stops deteriorating and waits indefinitely.

    What to replace rather than rescue

    Cardboard sleeves and boxes that were submerged are gone. They stay musty for years, and the smell is spores doing exactly what cardboard was never meant to host. Photograph them for the record if they matter, then bin them.

    Foam inserts, cloth bags and anything with a felt lining go the same way.

    The lesson worth keeping

    Whatever was on the floor is what you lost. The next shelf up survived.

    That single observation is worth more than any rescue technique here, and it costs nothing at all to apply before the next time.

  • Where a collection should actually live

    Everyone who keeps old hardware and media eventually runs out of room in the house, and the loft is where the overflow goes. It is the worst place in the building for the purpose, and the reason has nothing to do with dust or heat.

    The loft is a different climate from the rest of the house

    Above the insulation, a loft tracks the outside temperature with a lag. It gets colder at night than any room below it and warmer on a summer afternoon than anywhere else in the building, and it does that every day of the year.

    For a boxed collection, the temperature swing is the mechanism. Each cycle moves moisture in and out of cardboard, paper sleeves and the labels on disks. Over a few years, sleeves soften, inlays cockle, and anything with adhesive in it, which is most cassette and tape-based media, starts to let go.

    A roof leak is slow, local and invisible

    The worst case is not the swing. It is a failed roof covering, because a roof is the one part of the building nobody looks at, and a slow leak is quiet.

    A single slipped slate or a tired flashing admits very little water, and it admits it in the same place every time it rains. That water lands on whatever is directly beneath. From inside the loft, there is nothing to see until a box is already soft, because the staining is on the top surface where the torch does not reach.

    This is why it is worth getting someone up there before the problem arrives rather than after. If you have no idea who covers your area, find a local roofing contractor through a directory rather than through the first ad you are shown, and ask for a condition report rather than a quote. A roof inspected every few years is cheaper than any single collection it is sitting above.

    What to look for from the hatch

    Go up on a dry day with a torch, after a wet week. Daylight through the covering is obvious and rare. The useful signs are subtler.

    Dark fan-shaped staining on the underside of the boards or the felt, concentrated around one point. Rust streaks on nail heads. A tide line on a rafter. Any patch of insulation that is compressed and discoloured, which means it has been wet repeatedly and has lost its loft.

    Look along the line where the roof meets a wall or a chimney. Flashings fail before coverings do.

    What to do with the collection meanwhile

    Nothing stays on the loft floor. Shelving off the joists, lidded plastic crates rather than cardboard, and nothing directly under a valley, a chimney or a soil vent.

    Media you genuinely cannot replace does not belong up there at all, whatever the container. The loft is for the duplicates and the shelf-filler boxes. The irreplaceable items want to be in the heated part of the house, where someone would notice a problem in a week rather than in a decade.

  • Running a period-accurate machine versus emulating one

    Running a period-accurate machine versus emulating one

    Two routes lead to running software from twenty-five years ago. Assemble hardware from the period, or emulate it on a current machine. Both work. They suit different purposes, and the choice is worth making deliberately rather than by default.

    The case for real hardware

    Period hardware gives behaviour that is correct by definition, because it is the thing being reproduced. Timing, audio hardware quirks, video output characteristics and input latency are all simply what they were.

    Audio is where this shows most clearly. Sound cards of the era had distinctive characteristics from their synthesis chips and analogue output stages. Emulation of these has improved enormously and remains an approximation of something that varied between individual cards and even individual units.

    Display output matters too. Games designed for cathode ray tubes assumed the way those displays handled scan lines and colour bleed, and some art depends on it in ways that look different on a sharp flat panel.

    The costs, which are not only financial

    • Components fail. Capacitors degrade, drives lose alignment, disks develop errors. Maintenance is ongoing, not one-off.
    • Getting data onto the machine is a project of its own, since interfaces have moved on.
    • Specific combinations of hardware still need the driver and configuration work the era demanded.
    • Space and power are real constraints that get underestimated at the planning stage.

    The maintenance point is the one most people underestimate. A working period machine is not a stable state but a process. Anyone whose actual goal is playing games rather than maintaining hardware should be honest about which activity they are signing up for, because it is largely the second.

    The case for emulation

    Emulation is available immediately, costs nothing, and has enormous practical advantages: save states, adjustable speed, straightforward file transfer, no maintenance and no failure of irreplaceable parts.

    It is also, for a great deal of software, accurate enough that the differences are undetectable in play. Mature emulators for well-documented systems have had decades of work and correct behaviour that was originally wrong.

    The remaining gaps are narrow and real. Analogue audio character, precise timing in edge cases, and anything depending on undocumented hardware behaviour are where approximations persist. For most purposes these do not matter. For verifying a specific claim about how something behaved, they might.

    A workable way to choose

    The question that resolves it is what you are actually trying to do.

    • Playing games for enjoyment: emulate. The convenience advantage is enormous and the fidelity gap is small.
    • Verifying a specific behaviour or timing claim: real hardware, or at minimum a second emulator to cross-check against.
    • Enjoying the hardware itself as an object: real hardware, and the maintenance is part of the appeal rather than a cost.
    • Archiving media: real hardware, since reading original disks and discs properly needs original drives.

    That last one is worth separating out. Reading a floppy or an unusual disc format correctly is a hardware job, and it is time-sensitive in a way the others are not. Media degrades, and drives capable of reading it are becoming scarcer. Anyone holding original media that has never been imaged has a task with a deadline, whatever they decide about playing the games.

    The middle path most people end up on

    In practice a lot of people run emulation for everyday use and keep one modest period machine for the things emulation does not cover, particularly reading media. This gets most of the benefit of both without the maintenance burden of a full period setup.

    It is also the arrangement that survives losing interest for six months, which no amount of enthusiasm makes unlikely.

  • What gets lost when a game is remastered

    A remastered rerelease is generally good news. A game that was awkward to run becomes easy to run, reaches a new audience and returns to sale. It is also, quietly, a substitution: the version people can obtain is no longer the version that was originally released.

    What tends to change

    Remasters vary enormously in scope, from a compatibility wrapper around the original executable to a substantial rebuild. Even at the light end, changes accumulate.

    • Art is rescaled or replaced, changing how the game looks at its own intended resolution.
    • Audio is re-encoded or re-recorded, and licensed music is sometimes removed entirely.
    • Controls and interfaces are modernised, altering how the game feels to operate.
    • Bugs are fixed, including ones that had become part of how people played.
    • Content is occasionally cut for licensing or other reasons, rarely with a prominent note.

    The music case is the most consequential and the least discussed. Where a soundtrack was licensed for a limited term, a rerelease may have to replace it. The game is otherwise complete and a substantial part of its identity has been substituted.

    The bug question is genuinely difficult

    Fixing bugs sounds unambiguous. In practice some bugs became load-bearing. Techniques built on unintended behaviour, speedrunning routes, and in a few cases whole communities of play depend on the original engine doing something it was not meant to do.

    A remaster that fixes those bugs is more correct and less faithful. There is no answer that satisfies everyone, and the reasonable approach is to document what was changed so people can make an informed choice. That documentation is frequently absent.

    Availability is the real preservation issue

    The mechanism that matters is not the remaster itself but what happens to the original. Where the original stays on sale alongside it, nothing is lost and everyone is served.

    Frequently it does not. The original is delisted, and the only purchasable version becomes the remaster. At that point the original exists only in copies already held by individuals, and its availability depends entirely on the second-hand market and on private collections.

    This is a strange outcome for a medium that generates so much scholarship and discussion. The version people write about becomes unobtainable while a modified version is heavily promoted, and over time the modified version is what everyone actually experiences.

    Practical notes for anyone who cares about the original

    • Where both versions are available, obtaining the original as well costs little and cannot be done retroactively once it is delisted.
    • Keep physical media where it exists, and image it properly, including any audio tracks.
    • Record which version you have. A remastered installation and an original are not interchangeable for research purposes, and the difference is not always visible.
    • When writing about a game, say which version was used. This is basic and routinely omitted.

    Not an argument against remasters

    Remasters keep games playable and commercially alive, and the alternative for many titles is being unavailable in any form. That is plainly worse.

    The argument is narrower: a remaster is a new edition, not a restoration, and treating it as identical to the original quietly corrupts the record. Editions are a solved problem in other media, where nobody confuses a revised edition with a first, and the conventions for noting the difference are well established.

    Games writing has not yet developed the same habit, and the cost of that is a body of discussion where nobody can tell which version anyone is talking about.

  • Reading an old game’s configuration files without breaking anything

    A large share of problems with old PC games are solved in a text file rather than an options menu. Games of this period externalised far more than they exposed, and the file holding those values is usually sitting in the installation directory in a readable format.

    Where the values live

    Several conventions coexisted, and a game may use more than one at once.

    • Plain configuration files in the game directory, often with an obvious extension and readable structure.
    • Console variable dumps, written by the engine itself, listing every setting the console can change.
    • Binary settings files, typically produced by an installer recording hardware choices.
    • Registry entries, increasingly common toward the end of the period, holding install paths and hardware settings.

    The console variable dump is the richest target. Engines with a console frequently wrote out every variable and its current value, which means the file is simultaneously the settings and a complete list of what can be set. Reading one tells you what the engine can do.

    The rules that prevent an evening being wasted

    Configuration editing goes wrong in predictable ways, all of which are avoidable.

    • Copy the file before changing it. This single habit prevents nearly every unrecoverable outcome.
    • Change one value at a time and test. Changing six and finding the game broken tells you nothing useful.
    • Preserve the line ending style of the original file. Some parsers of this era are less forgiving than you expect.
    • Close the game first. Many engines rewrite their configuration on exit and will overwrite edits made while running.

    That last one is responsible for a great deal of confusion. An edit is made, the game is closed, the edit has vanished, and the conclusion drawn is that the setting is ignored. In fact the setting was applied and then overwritten by the engine’s own save on exit. Editing with the game closed avoids it entirely, and marking the file read-only afterwards is the usual approach where an engine insists on rewriting values.

    Values worth knowing about

    Certain settings recur across engines of this era and are frequently absent from the menus.

    Field of view is the most commonly sought, usually stored as a number that the menu never exposes. Raising it helps on widescreen displays, though it is worth confirming whether the game widens the view or crops it vertically.

    Frame rate limits and sound buffer sizes are similarly external, and both are common causes of problems on modern hardware where the original defaults assumed much slower systems.

    Install paths and drive letters are the other big category, recorded at install time and consulted forever after. A game that cannot find its data files after a folder move is usually reading a path from one of these files, and correcting it there is far quicker than reinstalling.

    When the file is binary

    Binary configuration is a harder case and generally not worth attacking directly. The values are usually settable another way: through the game’s own setup utility, which still runs in most cases, or through a console at runtime.

    Where a setup utility exists, running it is nearly always faster and safer than editing bytes. These utilities were built to write exactly this file correctly, and they still do.

    Recording what you changed

    Keeping a short note of edits pays off repeatedly, because these problems recur. Reinstalling the game, moving it to another machine, or returning to it after a year all mean redoing the same work, and reconstructing which four values mattered is far slower than reading a note.

    A plain text file beside the backup of the original configuration is enough. The point is not documentation for its own sake, but that future-you will otherwise repeat the entire diagnostic process from the beginning.

  • Patch culture before automatic updates

    A game bought on disc in 1999 was the version on the disc, permanently, unless the player did something about it. There was no update check, no background download and no notification. Patches existed, and finding out about them was the player’s problem.

    How people actually found out

    Discovery ran through the enthusiast press, cover discs, and word of mouth on forums and newsgroups. A magazine might mention that a patch had been released; the disc on the cover might carry it. Otherwise, a player had to think to check the publisher’s website, which required knowing it existed and having a connection worth using.

    Substantial numbers of people therefore played the shipped version indefinitely, bugs and all, unaware that fixes existed. This was normal rather than exceptional, and it shaped how developers thought about launch quality: the disc version was, for a large share of the audience, the only version.

    Applying a patch was a manual operation with real risk

    A patch was an executable that modified an installation in place. It usually checked the version it was upgrading from and refused if that did not match, because patches were often incremental: 1.0 to 1.1, then 1.1 to 1.2, with no direct route from 1.0 to 1.2.

    Miss a step and the sequence broke. Apply patches in the wrong order and the installation could end up in a state no patch recognised, with reinstallation the only fix. Anyone who modified game files, which included most people running mods, could find a patch refusing to run because a checked file no longer matched what it expected.

    • Patches were frequently one-way. Reverting meant reinstalling from disc and starting the chain again.
    • Saved games often did not survive a version change, and this was not always documented prominently.
    • Mods were version-specific, so patching could break a working setup with no route back short of reinstalling.

    Why version numbers still matter today

    Anyone installing one of these games now inherits the whole situation. The disc is at its original version. The patches that once lived on a publisher’s server may or may not still be findable. And any modification being used will specify a version requirement written when that version was current.

    This produces a recurring and confusing failure: a mod that will not load, with an error suggesting file corruption, when the actual problem is a version mismatch that the mod’s documentation stated plainly two decades ago.

    Digital rereleases complicate it further. A rereleased version is usually the final patch level, sometimes with additional changes for modern compatibility. That is convenient for playing and awkward for mods, because it may not correspond exactly to any version a mod was ever tested against.

    The practical approach

    Establish what version an installation is at before doing anything else. Most games report it on a menu screen or in a file header, and knowing it converts a vague problem into a specific one.

    Then read the mod’s documentation and believe it. Where it names a version, that is not a suggestion. Where a patch is required and no longer available from its original source, community archives frequently hold it, and this is one of the more valuable things such archives do.

    What was lost when updates became automatic

    Automatic updating is better in nearly every respect. Fixes reach everyone, the version is knowable, and nobody has to maintain a mental map of patch chains.

    What it removed is the ability to stay put. A player who preferred an earlier version, or needed one for a mod, could simply not install the patch. That option has largely gone, and with it the ability to preserve a specific version of a game as it existed at a specific moment.

    For a game as a product this rarely matters. For a game as an artefact, being unable to hold a version still is a genuine loss, and one that will become more visible as more of the current era’s software becomes historical.

  • DOS memory management, and why old games asked for so much of it

    Anyone running DOS games encounters the memory question quickly. A game demands a quantity of conventional memory that appears to be available and is not, or wants expanded memory when extended memory is present, or refuses to start on a machine with vastly more RAM than it needs.

    These are not arbitrary requirements. They come from a hardware constraint that shaped a decade of PC software design.

    The 640K boundary

    The original PC architecture could address one megabyte. The lower 640 kilobytes were allocated to programs. The remaining 384 kilobytes were reserved for hardware: video memory, adapter firmware, the system BIOS.

    The 640 kilobyte figure was not a mistake so much as a generous allocation that stopped being generous. Programs grew, the boundary did not move, and the entire subsequent history of DOS memory management is workarounds for a limit that could not be raised without breaking compatibility.

    Four kinds of memory, doing different jobs

    • Conventional memory: the first 640K, where DOS programs actually run. Always the scarce resource.
    • Upper memory: the 384K reserved region above it. Unused portions could host drivers, freeing conventional memory.
    • Expanded memory: additional memory accessed through a window mapped into the upper region, a page at a time.
    • Extended memory: memory above one megabyte, accessible in protected mode but not directly by ordinary DOS programs.

    Expanded and extended are the pair that cause the most confusion, and the names do not help. Expanded memory was a bank-switching scheme, originally implemented on add-in cards, that let a program see a small window onto a large pool. Extended memory was simply the memory beyond one megabyte on a capable processor, which required switching the processor’s mode to use.

    Later systems provided expanded memory by emulating it using extended memory, which is why a machine can offer either depending on how it is configured, and why a game that demands one may fail on a machine configured for the other.

    Why games wanted conventional memory specifically

    Game code and its most performance-critical data had to live in conventional memory to be reachable without paging or mode switching. Anything else meant overhead in the parts of the code that could least afford it.

    This is why loading a mouse driver, a sound driver and a CD-ROM driver could stop a game running. Each occupied conventional memory. Between them they might take a hundred kilobytes from the 640 available, and the game needed most of what remained.

    Hence the era’s characteristic ritual: boot configurations that loaded the minimum set of drivers for a particular game, with everything possible relocated into upper memory. People maintained several such configurations and chose between them at startup.

    What this means today

    Running these games now usually means an emulated DOS environment, which removes the hardware constraint but reproduces the software model. The 640K limit still applies inside the emulation, because the games depend on it existing.

    The practical difference is that resources are no longer genuinely scarce. Emulators can provide expanded and extended memory generously and load drivers into upper memory without the fiddly optimisation the original hardware demanded.

    • If a game reports insufficient memory despite plenty being configured, check which type it wants. It is usually asking for conventional memory specifically.
    • Load only the drivers a given game needs. A CD driver present for a game that does not use one is pure waste.
    • Where a game offers a choice of memory model at install time, the choice is frequently recorded in a configuration file and can be changed without reinstalling.

    The underlying skill has not changed much. Working out what a DOS game wants is mostly reading its documentation carefully and believing what it says, because these requirements were documented precisely at a time when getting them wrong meant the software did not run at all.

  • Mod communities and the archive problem nobody owned

    Mod communities and the archive problem nobody owned

    A large modding community produced, over a few years, thousands of levels, hundreds of substantial modifications and a written record of discussion around them running to millions of words. Very little of that was archived deliberately. What survives is mostly accident.

    The infrastructure was personal

    Community infrastructure of the period ran on individual effort. Someone paid for hosting. Someone ran the forum software. Someone maintained the file index, usually as a hobby, alongside a job and a life.

    This worked well while the person remained interested and solvent. It failed completely when they did not, and the failure was typically abrupt: a server bill unpaid, a domain not renewed, a disk failure without backups. The community found out when the site stopped responding.

    There was rarely a handover mechanism, because nobody had planned for an ending. The material was not owned by an organisation that could pass it on. It was on a machine belonging to a person who had moved on.

    Duplication was uneven in a way that skewed what survived

    Files that circulated widely survive well. A popular modification, mirrored across many sites and burned onto cover discs, exists in many copies and is straightforwardly findable today.

    Everything around it survives poorly. The discussion that explained what a mod was doing, the tutorials that taught people how, the arguments about technique, the credit for who made what: this material existed in one place, on one forum, and when the forum went so did all of it.

    The result is an archive weighted toward artefacts and empty of context. We have the files. We frequently do not have any record of why they were made, by whom, in what order, or what the people making them thought they were doing.

    Attribution decays fastest of all

    Credit was often recorded only in a text file inside an archive, or in the forum post announcing a release. Text files survive if the archive does. Forum posts generally did not survive.

    Repacked and rehosted files frequently lost the accompanying documentation, either through carelessness or through a hosting site’s own format requirements. A file that has passed through three mirrors may arrive with no author information at all.

    • Keep the original archive intact rather than extracting and rehosting the contents. The packaging holds information.
    • Preserve readme and documentation files with the same care as the content. They are frequently the only record of authorship.
    • Where a file’s origin is uncertain, say so rather than guessing. A confident wrong attribution is worse than an honest gap.

    What actually worked

    The efforts that succeeded share a small number of unglamorous properties. Material was mirrored across more than one independently controlled location. Metadata was stored alongside files rather than only in a database. Someone documented how the collection was organised, so a stranger could continue it.

    None of that requires funding or institutional backing. It requires deciding early that the collection should outlive the person maintaining it, and that decision is almost never made early, because at the start nobody thinks of a hobby project as something with a succession problem.

    The uncomfortable conclusion

    A significant share of what an active creative community produced is gone, and its absence is not proportional to its quality. Losses correlate with obscurity, with hosting arrangements and with the personal circumstances of individuals, not with whether the work was any good.

    For anyone maintaining a collection now, the useful question is simple and slightly bleak: if you stopped tomorrow, what would happen to it? If the honest answer is that it would disappear, that is the problem to fix, and it is a considerably smaller job than it will be later.

  • How texture packing worked before texture atlases were automatic

    How texture packing worked before texture atlases were automatic

    Look closely at PC game art from the late 1990s and patterns emerge: textures at consistent small sizes, palettes shared across unrelated surfaces, repetition that looks deliberate and is often necessity. These are the fingerprints of memory limits that no longer exist.

    The constraint

    An early consumer 3D accelerator might carry four megabytes of memory, shared between the frame buffer, the depth buffer and textures. After the buffers took their share, what remained for textures was small, sometimes under two megabytes.

    Textures had to be resident in that memory to be used. Anything not resident had to be transferred across the bus mid-frame, which was slow enough to be visible as a stall. Managing residency was therefore a central performance concern rather than a detail.

    There were hard shape constraints too. Dimensions generally had to be powers of two, and many chips imposed limits on maximum size and on aspect ratio. An artist could not simply produce an image of whatever size suited the surface.

    What artists did about it

    The responses are visible in the finished art once you know to look for them.

    • Small tiles repeated across large surfaces, rather than large unique textures. A 128×128 tile covering a whole wall costs a fraction of a unique texture.
    • Detail concentrated where the player would be close, with distant geometry given the cheapest possible surfaces.
    • Shared palettes across a level, so that a single palette load served many textures.
    • Geometry designed to hide seams, because tiling seams were unavoidable and the alternative was hiding them with level layout.

    The tiling aesthetic that reads as period style today was substantially a memory budget expressed as art direction. It happens to have aged well, which is partly luck and partly that constraints tend to produce consistency.

    Atlases, assembled by hand

    Combining many small textures into one larger image reduces the overhead of switching between them, and the technique was well understood at the time. What did not exist was reliable automation.

    Atlases were frequently laid out by hand, or with in-house tools written for one project and never generalised. That made them expensive to change. Adding one texture to a full atlas could mean relaying out the whole thing and updating every coordinate that referenced it.

    The consequence was that atlas layout got frozen early in a project, and later art had to fit whatever space remained. Art produced late in development is sometimes recognisably squeezed into gaps, which is not a judgment on the artist.

    Filtering created a further trap. Bilinear filtering samples neighbouring pixels, so a texture adjacent to another in an atlas could bleed colour from its neighbour at the edges. Preventing it meant padding borders, which wasted the space the atlas was meant to save. Getting that balance right was a real craft skill.

    Compression arrives

    Hardware texture compression changed the calculation substantially, offering a fixed compression ratio with decompression handled in hardware at no cost during rendering. Roughly four times as much texture in the same memory, for a quality loss that varied by content.

    It was not free of character. The compression schemes handled smooth gradients and photographic detail well, and struggled with sharp colour transitions and particularly with normal maps, producing blocking artefacts around hard edges. Artists learned which content compressed cleanly and which needed to stay uncompressed, and budgeted accordingly.

    Why this matters when looking at old assets

    Anyone extracting or examining textures from games of this era should expect to find them in hardware-specific compressed formats, at power-of-two sizes, often atlased with padding, and sometimes with palettes stored separately from the image data.

    A texture extracted without its palette is not a corrupted file. It is half a file. Similarly, an atlas extracted without the coordinate data that maps surfaces onto it is a picture of a lot of textures rather than a set of textures.

    The information needed to reassemble these things is usually present in the game data somewhere. It is just rarely in the same place as the images, because in the original pipeline nothing needed it to be.

  • Source ports explained: what they change and what they must not

    Source ports explained: what they change and what they must not

    When the source code to a game engine becomes available under a licence that permits redistribution, source ports follow. Someone compiles it for a current operating system, fixes what no longer works, and publishes the result. For a number of significant games this is now the normal way to play them.

    What separates a good port from an awkward one is rarely technical skill. It is discipline about which category a given change falls into.

    The three kinds of change

    Nearly every modification to an old engine falls into one of three buckets, and conflating them is the source of most disagreements about ports.

    • Platform repair: making the code build and run correctly on hardware and operating systems it predates.
    • Capability extension: raising limits, adding resolutions, supporting modern input and audio devices.
    • Design change: altering how the game plays, looks or feels beyond what the original did.

    The first is uncontroversial and necessary. The second is usually welcome but occasionally has side effects. The third is where ports diverge, and where a port that is excellent for one purpose becomes wrong for another.

    Platform repair is subtler than it sounds

    Old engines are full of assumptions that were true and are no longer. Fixed word sizes, particular byte ordering, direct hardware access, timing derived from processor speed, memory layouts that a modern allocator will not reproduce.

    Timing is the recurring troublemaker. An engine that tied its update rate to a hardware timer or, worse, to a counted loop, behaves entirely differently on a fast machine. Fixing this properly means separating simulation rate from rendering rate, which is a real change to how the engine runs even though the intent is purely to restore original behaviour.

    This is where ports quietly diverge from each other. Two ports can both claim faithful behaviour and produce measurably different results, because reproducing original timing on different hardware requires choices, and reasonable people choose differently.

    Capability extension and its side effects

    Raising a limit sounds harmless. Frequently it is. Sometimes the limit was load-bearing.

    Games written against hard engine limits occasionally relied on the behaviour at the boundary. Content built when a limit existed may have been designed around what happened when it was approached. Removing the limit changes that content’s behaviour without touching the content.

    Higher resolutions carry a similar catch. Widening the field of view shows more of the world, which can reveal things the original never intended to be visible from a given position, and can alter difficulty in games where limited sightlines were part of the design.

    None of this argues against extension. It argues for making it optional and documenting what it affects.

    Why faithful modes matter

    The best ports offer a mode that reproduces original behaviour as closely as the platform allows, and make it clearly labelled rather than buried. This serves two audiences that would otherwise be in permanent conflict.

    Someone playing for enjoyment usually wants the modern conveniences: proper resolutions, sensible input handling, no crashes. Someone studying the game, verifying a claim about it, or reproducing a documented behaviour needs the original, quirks included.

    A port that only offers the improved version is fine as a game and useless as a reference. A port that only offers strict fidelity is useful as a reference and frustrating to play. Offering both costs relatively little and serves everyone.

    Choosing one

    • Check whether the port documents its deviations from original behaviour. Ports that do are usually the ones that thought about it.
    • Prefer ports that keep the original data files untouched and load them rather than converting them. Conversion is a one-way door.
    • For anything where behaviour matters, test the specific thing you care about rather than trusting a compatibility claim.

    The wider point is that a source port is an interpretation, not a copy. It is usually a very good interpretation, made by people who cared enough to do the work for nothing. But something that has been rebuilt has been decided about, and knowing which decisions were made is part of using it well.