HN Debrief

Making Graphics Like it's 1993

  • Programming
  • Game Development
  • Graphics
  • Developer Tools
  • Open Source

The post is a long behind-the-scenes writeup on making a new FPS that looks and feels like an early 1990s PC game. The developer explains the self-imposed limits that define the project, such as low resolution rendering, palette-driven lighting, sprite-based assets, and a software-rendered world. The piece is not just nostalgia bait. It shows the actual production pipeline, including rendering 3D models into sprites, quantizing them into a restricted palette, and using small scripts to generate effects like gib animations. That combination of engine work, art direction, and custom tooling is what grabbed people. Many started by assuming this was just a Wolfenstein or Doom reskin, then realized the author had built both the game code and the asset workflow from scratch.

If you are building stylized software, this is a strong reminder that hard constraints plus good internal tooling can create a more coherent product than chasing modern abundance. It also shows there is still real appetite for detailed, human-written engineering writeups that explain taste, tradeoffs, and implementation instead of just showing the finished output.

Discussion mood

Strongly positive and a little awed. People admired the craft, the coherence of the visual style, and the fact that the article explained real implementation choices instead of hand-waving. The only sour notes were minor nitpicks about historical purity, AI-related signaling, and off-topic culture-war bait.

Key insights

  1. 01

    Build engine was not Doom with another name

    The old-engine comparisons got sharper once people separated Doom, Wolfenstein 3D, and Build instead of lumping them together. Build used sectors and portals, not BSP, which is why games like Duke Nukem 3D and Shadow Warrior could fake tricks like room-over-room, moving geometry, bridges, and transparent water in ways that felt more three-dimensional than their underlying data structures really were. That correction helps place the article's engine on the simpler raycaster side of the family rather than the later portal-heavy branch.

    If you borrow a retro rendering model, be precise about which lineage you mean because the map format, level design affordances, and content tooling all change with that choice. A nostalgic look can hide very different engine tradeoffs underneath.

      Attribution:
    • badsectoracula #1
    • bluedino #1
    • Grumbledour #1
    • mrob #1
    • classichasclass #1
  2. 02

    Cheap lighting depended on tiny lightmaps and fixed point

    A practical addition to the article was the reminder that dynamic lighting in this style often came from tiny lightmaps and lookup tables rather than expensive per-pixel math. Updating an 8x8 or 16x16 light grid a few times per second was enough to get flickering torches and projectiles that light a corridor. Fixed-point arithmetic made that viable on period hardware and also gave deterministic output across machines, which is why older systems like TeX leaned on it too.

    If you want retro-style dynamic lighting today, start with coarse light data and lookup tables before reaching for full-resolution effects. You can keep the look, cut cost, and make your content pipeline easier to reason about.

      Attribution:
    • Teslazar #1
    • pragma_x #1
    • dhosek #1
  3. 03

    Palette tricks still do real visual work

    Several people highlighted that palette swaps and palette rotation were not just nostalgia flourishes. They were a serious way to animate water, lava, plasma, enemy variants, and shaded environments at almost no runtime cost. Mid-frame palette changes and shaded colormap tricks could stretch limited art much further than extra sprites ever could. The Excel 97 flight simulator easter egg came up as another example of how far that approach can go when paired with dithering.

    If you are chasing a constrained visual style, treat the palette as an active rendering system rather than a static color list. It can give you animation, variety, and lighting without expanding asset count.

      Attribution:
    • robterrell #1
    • EvanAnderson #1
    • keithnz #1
    • itomato #1
    • rezmason #1
  4. 04

    The internal tools are the real multiplier

    What impressed people most was not the renderer alone. It was the surrounding toolchain. The Python and Blender scripts that generate spritesheets, gibs, and post-processed assets are what make a solo project feel like a studio pipeline. That is also why the art stays coherent. The tools encode the style rules so the developer does not have to re-solve them by hand for every asset.

    When a small team has a strong visual target, invest early in scripts that bake your style decisions into the pipeline. That is how you get consistency and throughput without hiring a full content department.

      Attribution:
    • ferguess_k #1 #2
    • kridsdale1 #1
    • sklopec #1
  5. 05

    Modern GPUs make brute-force rendering viable here

    The most concrete engineering advice came from people responding to the author's plan for a hardware path. For levels this small, modern GPUs can often render the entire scene with a depth buffer and alpha-tested sprites faster than any elaborate occlusion system. One commenter argued that trying to preserve old-school visibility logic on current hardware could actually make performance worse. The author agreed that a single modern character model can exceed the polygon count of a whole level in this kind of game.

    If you need higher resolutions or accessibility options, do not assume you must faithfully port every retro optimization. Profile the dumb path first. On modern hardware, simple full-scene rendering may be the right answer.

      Attribution:
    • sklopec #1 #2
    • badsectoracula #1
    • pjc50 #1
    • trumpdong #1

Against the grain

  1. 01

    The nostalgia frame is selective and a bit performative

    A skeptical read was that the project oversells its purity. The article talks about early-90s techniques, but the actual workflow uses modern tools like Blender and contemporary solo-dev conveniences. The pushback to that critique was that period games also relied on off-the-shelf 3D packages and specialist pipelines. The useful point is not whether the project is perfectly authentic. It is that the boundary between historical method and modern reinterpretation is blurrier than the pitch suggests.

    If you market a project around technical authenticity, expect people to inspect the claim closely. Be explicit about which parts are historically faithful and which parts are modern substitutions so the framing does not become the story.

      Attribution:
    • mg794613 #1
    • Supermancho #1
    • mrob #1
    • ogurechny #1
  2. 02

    Some game feel choices may be too decorative

    One gameplay nitpick cut against the praise for polish. Destructible vases taking multiple shots made the weapon feel weak because the object reads as fragile and mostly cosmetic. That is a small point, but it gets at a real risk in stylized projects. Once the presentation looks convincing, players start holding interactions to the same standard.

    Do a pass on low-stakes interactive props and ask whether their response matches what the art implies. Tiny mismatches can make combat feel off even when the rendering is excellent.

      Attribution:
    • mrob #1

In plain english

alpha-tested sprites
Sprites rendered with a simple transparency cutoff so fully transparent pixels are discarded rather than blended.
BSP
Binary Space Partitioning, a way of splitting space into regions that helps with rendering visibility and collision in games like Doom.
fixed-point
A numeric format that stores fractional values using integers with an implied decimal position, often faster and more deterministic than floating point on older hardware.
framebuffer
A region of memory that stores pixel values for the image being displayed on screen.
gibs
Small flying pieces of a destroyed character or object, used as a gore or destruction effect in shooters.
mode 13h
A classic VGA graphics mode that provides a linear 320x200 framebuffer with 256 colors, popular for DOS game programming.
sprite
A 2D image used as a game object, character, effect, or pickup, often drawn in a 3D-looking world.
VGA
Video Graphics Array, a PC graphics standard from the late 1980s that popularized 320x200 256-color graphics modes.

Reference links

Rendering and retro graphics techniques

Libraries, tools, and asset pipelines

  • SDL2 ARGB8888 software rendering gist
    Shared as a minimal cross-platform path to display a software-rendered framebuffer with SDL2.
  • PyDPainter
    Suggested for creating art with a Deluxe Paint-like workflow.
  • Aseprite
    Suggested as a modern sprite and pixel art editor for this style of work.
  • KritaView3D
    Referenced as a custom Krita-related tool used in another retro sprite generation pipeline.

Example projects and engine references

  • JonoF Build engine forum post
    Linked to support the correction that Duke Nukem 3D's Build engine was not BSP-based.
  • Post Apocalyptic Petra benchmark video
    Used as evidence that brute-force rendering of low-poly retro scenes can run extremely fast on modern GPUs.
  • Chunked z-level raycaster repo
    Shared as another hobby raycaster project with multiple height levels and memory-efficiency questions.
  • Inferno
    Linked as an earlier project showing the author's prior art and visual style.
  • Worship
    Linked as another earlier project by the same author to show artistic consistency.

Talks and historical examples