Building a Wolf 3D-Style Engine in PlayBASIC with Affine-Textured Polygons

The idea behind this project was simple: Could I recreate a Wolfenstein 3D-style engine in PlayBASIC while maintaining good perspective but using affine texture-mapped polygons instead of traditional raycasting?

Floors and Ceilings: Subdivision for Perspective

Classic Wolfenstein 3D engines rely on raycasting, but I wanted to explore using polygons. This introduced two key challenges: rendering walls and handling floors/ceilings. I tackled floors first by subdividing floor tiles near the camera, ensuring that closer surfaces were represented with a denser set of polygons. This approach worked well, maintaining an accurate perspective without excessive computational overhead.

Walls: Adaptive Subdivision

I applied the same technique to walls, subdividing them based on their distance from the camera. Surfaces closer to the viewer were represented with more polygons, while those farther away used fewer. This adaptive approach preserved scene perspective while optimizing performance.

Ensuring Proper Polygon Order

A major challenge with polygon-based rendering is ensuring proper drawing order. Since walls, floors, and ceilings are drawn as independent polygons, z-fighting (incorrect layering of polygons) can be an issue. To address this, I implemented a two-pass rendering system:

1. 1. First, floors and ceilings are drawn.
2. 2. Then, walls are rendered on top.

This method prevents z-popping artifacts commonly seen in painters’ algorithms and produces a visually appealing scene.

Enhancing the Classic Wolf 3D Look: Adding Light Mapping

To push beyond the classic Wolfenstein 3D aesthetic, I added a light mapping pass. Implementing this in PlayBASIC required rendering the scene twice—essentially brute force—but the cost was only around a 20% performance hit. The visual improvement, however, was well worth it.

The process involved:

1. 1. Drawing the texture-mapped scene.
2. 2. Overlaying a Gouraud-shaded version of each triangle, where each pixel’s color was alpha-blended with the background.

This resulted in a real-time light-mapped scene with a Doom-like atmosphere, enhancing immersion and depth.

Pushing Further: 3D Polygonal Characters Instead of Sprites

A long-standing idea I wanted to explore was replacing traditional 2D sprites with 3D polygon-based characters. This concept originated from my work on a rendering engine called "Reality" for Amiga computers back in 1995, which aimed to integrate both sprites and 3D objects within a scene.

Implementing 3D Objects

To bring this concept into PlayBASIC’s Wolf 3D engine, I needed a way to load and render 3D models. I chose the DirectX ASCII format due to its simplicity. The loader extracted three key components:

Reality: The Lost Amiga 3D Engine

What Is Reality?

Reality was the name of our Wolfenstein 3D-style game engine, which became an umbrella term for anything related to that pursuit. The project aimed to create a fast and efficient first-person engine on a near-stock Amiga 1200 (020+FastRAM) in the mid-1990s. This archive contains the last known remaining compiled executables from my various attempts to achieve reasonable performance on the platform.

Originally, the Reality project was most active between 1994 and 1995. Apart from a few screenshots shared with close friends, it was never publicly released. The executables included here represent alpha-stage software—functional but far from stable. While they take over the system in as OS-friendly a manner as I knew at the time, modern systems may not handle them well.

About the Demos

Reality.exe - Ray Casting Experiment

This was the initial test of the engine, developed sometime in late 1993 or early 1994. The first major challenge was the chunky-to-planar (C2P) problem, where my initial attempts using unrolled bit sets failed spectacularly. While this approach might have worked for particle effects, it was a disaster for general-purpose rendering. However, after several iterations, I moved on to a bit-parallel rotation solution, which significantly improved performance.

This is the only version of Reality that employs a true ray-casting method. The scene is constructed by casting rays outward from the camera’s field of view, step by step, checking for wall collisions. Each map pixel represents a vertical wall strip, likely stored as 8-bit data, allowing for 256 unique wall textures.

Color depth was either 16 or 64 colors, which struck a balance between visual quality and conversion speed. This version laid the foundation for later advancements.

Map.exe - 64-Color 2D Polygon Walls

As development progressed, I re-evaluated the engine’s structure and opted for a different approach. Instead of a traditional grid-based map, I structured levels as a grid of evenly spaced vertices, where walls were formed by linking vertex pairs. This allowed for non-orthogonal walls and greater flexibility in map design.

Rendering involved rotating and projecting the sector vertices, which determined floor and ceiling heights. The scene was then processed polygon-by-polygon. For each wall, I interpolated across its top and bottom, computing its Z-depth and texture U-values. Instead of rendering strips immediately, the engine stored them in a Z-buffer, ensuring proper visibility sorting.

A unique optimization was that textures were stored rotated in memory, enabling rapid texel fetching using a simple 8-bit V-offset.

Project Reality - 256-Color Rendering & 3D Objects

By early 1994, the gaming world was in the grip of DOOM fever, and we ambitiously aimed to push Reality further. As Commodore's decline loomed, we set our sights on creating something akin to Blake Stone, but with even more complex environments and polygonal objects.

This demo showcases the most advanced features we implemented:

Thesius XII: Developing a Classic Amiga Shoot 'Em Up

Back in the golden age of the Amiga, I developed Thesius XII, a fast-paced shoot 'em up inspired by the arcade classics of the time. The game was my attempt at pushing the limits of the Amiga hardware while delivering an engaging and action-packed experience. Sadly, the game was never fully completed, but in 2000/2001, I released an 'as is' version featuring three levels. Despite missing final polish, it remains a nostalgic favorite for many retro gaming enthusiasts.

Inspiration and Design

The concept for Thesius XII was heavily influenced by IREM’s R-Type and Tecmo’s SilkWorm, two of my personal favorites. I wanted to create a game that blended intense shooting mechanics with strategic enemy patterns, requiring both reflexes and tactical movement. The art style and design leaned into the aesthetic of futuristic space battles, filled with vibrant explosions, detailed sprite work, and smooth scrolling backgrounds.

Technical Development and Features

The game was designed for a stock Amiga 500 running a 7MHz 68000 CPU, 512K memory, and the original chipset. Developing on this hardware came with its own set of challenges. Memory constraints, CPU limitations, and optimizing the rendering pipeline were crucial to maintaining smooth gameplay. One of the biggest hurdles was handling a large number of on-screen enemies without bogging down performance. To solve this, I implemented efficient sprite management and custom routines for object culling and collision detection.

Some of the standout features of Thesius XII included: