Original

Greetings!

I have previously written three articles on this topic:

Crafting an Arcanum Engine. Lesson 01. The Beginning

Crafting an Arcanum Engine. Lesson 02. Working with Game Files, Drawing the First Sprite

Crafting an Arcanum Engine. Lesson 03. Memory Management, Using Polymorphic Allocators

Now, however, I want to start a series of articles focused on using old, authentic hardware, software, operating systems, and development tools. I've decided to start the clock from 1995.

Prologue: A Dream Come True, But the Experiment Continues

The community of the classic RPG Arcanum: Of Steamworks and Magick Obscura was recently rocked by news: a developer named Alex completed a titanic effort to reverse-engineer the game's original engine. We now have its full, functional source code, which can be compiled for Windows, Linux, and macOS using the modern SDL3 library.

This is a dream come true. The game can now be improved, its long-standing bugs fixed, and new content added. Like many others, I plan to participate in this process. But this breakthrough made me think: how was such magic created back in the mid-90s? What was it like to build such an engine within that very era, with its hardware, software, and mindset?

Thus, this personal experiment was born. I will not be modifying the existing engine. I will attempt to write my own engine for Arcanum from scratch, as if it were 1995.

Part 1: The Essence of the Experiment. Not Nostalgia, But Digital Archaeology

In 1995, I was six years old. My memories of that era are of the Dendy console and cartoons, not lines of code. Therefore, my project is not about nostalgia. It is practical digital archaeology.

My goal is to immerse myself in the era to study it. To feel the same constraints, the same environment, and the same tools. This is an attempt to understand not what the developers did, but how and under what conditions they did it. To recreate their context and truly appreciate their genius and the incredibly complex decisions behind every pixel.

Two approaches to one world:

Alex's Approach (The Present): Take the finished engine and, using modern tools, untangle and improve it. This is precision surgery.

My Approach (The Past): Take a blank slate and, using the tools of that era, understand how such an engine could have been built originally. This is about growing an organism from scratch in its native environment.

This experiment is my bridge between eras, a way to pay tribute to the engineers of the past and remind us of the fundamental principles we sometimes forget in an age of abundant computing power.

Part 2: Rigs from the Past. A Detailed Look at a "Mainstream" 1995 PC

To truly understand the era, you need to know its foundation. Our target platform is a carefully balanced system where every component was a compromise between price and performance.

"Mid-Tier Gaming PC" Configuration:

• CPU: Intel Pentium 75 MHz
  
  Architecture: The first mass-market superscalar CPU (two pipelines). A revolution that taught the processor to execute two instructions per clock cycle.
  
  Cache: 16 KB (8+8 KB). That's 4000 times less than the cache of a modern CPU. A cache miss was a disaster.
  
  FPU: Built-in math coprocessor — a godsend for isometric 2D graphics.

• RAM: 16 MB EDO DRAM
  
  A realistic standard for games in 1995-96. Windows 95 "ate" 5-8 MB, leaving the game a precious 8-10 MB.
  
  Modules: 72-pin SIMMs, which had to be installed in pairs.

• Video Subsystem: S3 ViRGE-based card (2 MB VRAM)
  
  One of the first "3D accelerators for the masses." Its 3D was weak, but its 2D capabilities were excellent.
  
  VRAM: Dual-ported memory, allowing the CPU to write data while the RAMDAC simultaneously output it to the monitor.
  
  Resolutions: 800x600 in True Color, 1024x768 in High Color.

• Storage: Quantum Fireball HDD 1.2 GB
  
  Interface: IDE (ATA-2). Speed: 4-8 MB/s (compared to 5000+ MB/s for an SSD).
  
  Characteristics: 5400 RPM, 12-14 ms access time, characteristic "chattering" sound.

• Sound Card: Creative Sound Blaster 16
  
  The gold standard with 16-bit sound and a Yamaha OPL3 FM synthesizer for compatibility.
  
  The Headache: Manually configuring IRQ and DMA channels with jumpers on the card.

• Monitor: 15-inch CRT (ViewSonic 15GS)
  
  Resolution: 1024x768. Perfect color reproduction, zero latency, weight — 15 kg.

To visualize the difference between a 1995 PC and a modern one, it looks roughly like this: 😀

• Software and Tooling Constraints:
  
  Environment: Visual C++ 4.0. No IntelliSense, convenient refactoring, or quick search. Programming close to writing in a notepad.
  
  Information: No Google or Stack Overflow. Only the MSDN Library on CD-ROM and paper manuals. An error = hours of thoughtful analysis. Of course, I can't print out hundreds of pages, but I can always open a PDF on a second screen.
  
  Build Time: A full project rebuild took minutes. This was time for thinking, not for scrolling.

An important point to mention:

We will be emulating the computer using the 86box program. Finding such a PC now is problematic; it can be quite expensive, and it could easily get damaged during shipping. Therefore, emulation is one way to get hands-on with a 1995 PC.

The final setup:

It is within these constraints — 16 MB of RAM, 2 MB of video memory, and 75 MHz — that we will attempt to render the isometric world of Arcanum.

Part 3: Code Philosophy and Optimization as a Way of Life

The entire engine is written in C++. This is a conscious choice in favor of readability and portability, rather than assembly hacks.

Key Principles:

Simplicity and Portability. 95% of the code is the common core. The OS-dependent code (for Windows, Linux, DOS) does not exceed 2000 lines.

Minimal API. A thin abstraction layer for rendering, sound, and input. Each port implements it independently (via WinAPI, Xlib, direct VESA access).

Optimization is a Philosophy.

8-bit color buffer (256 colors). Reduces memory footprint and copy operations by 3-4 times compared to RGB.

Frustum Culling. Only the geometry visible to the camera is drawn, not the entire 100x100 tile map.

Optimized Software Rendering. Fast sprite-copying routines with transparency (color keying).

Minimization of Dynamic Memory Allocations.

In the future, these developments will be moved into the LDL library, whose goal is to give modern developers a tool for easily porting code to platforms of a bygone era, including 32-bit DOS via DPMI.

Part 4: A View from the Future. Lessons Lost in an Era of Abundance

Immersion in 1995 from the vantage point of 2025 is a shock of contrasts and an invaluable experience.

Programming in a Vacuum. The lack of internet is not a drawback, but a feature. It's a return to a state of deep work, which has become a luxury today. Waiting for compilation becomes a productive moment for contemplating architecture.

Tactility and Mindfulness. Installing software from CD-ROMs, fighting for every megabyte on the hard drive — this cultivates extreme mindfulness in every action.

Documentation as an Art. The necessity of reading manuals from cover to cover forms a systemic, rather than fragmented, understanding of technology.

I want this project to serve as a reminder that performance is born not from tons of assembly code, but from the elegance of solutions. That the most beautiful algorithms and optimizations are often born under the most severe constraints.

Part 5: What Makes 1995 So Appealing?

This isn't just a year; it's the era of the transition to 32-bit software. The beginning of DirectX. The promotion of 3D technologies for PC users — timid yet, but already polygonal 😀 Windows 95 finally conquered the world for decades to come. It was a pivotal year for IT. A new OS, new development tools, a new API.

Epilogue: Why?

This project is my personal way of paying tribute to the engineers and programmers who, with limited resources, created the magic we remember and love today. It's a way to better understand the present by studying the past.

And now, when the community has the source code of the original engine, my experiment has become part of something bigger. This is a dialogue. On one side — the power of a modern community, giving an old game a new life. On the other — the attempt of one developer to understand the origins of that life by voluntarily returning to the environment where it was born.

Great games never die. They live on in the memory of fans, in the code of modern ports, and in crazy experiments like mine.

In the next article, I will install Windows 95, drivers, set up Visual C++ 4.0, and immerse myself in the harsh realities of 1995 programming. We will lay the foundation for our project.

What do you think of the project?