Raycast FPS in COBOL: Can a 60-Year-Old Language Render 3D?

Why Build a Raycast FPS in COBOL?

When the hacker community turns a business-computing relic into a 3D shooter engine, the result is equal parts absurd and instructive. COBOL — the Common Business-Oriented Language first standardized in 1959 under the CODASYL consortium with significant contributions from Admiral Grace Hopper — was designed to process payroll runs and insurance claims, not to render first-person corridors.

Yet periodic projects on platforms like Hackaday and GitHub demonstrate that hobbyists are doing exactly that: wiring COBOL programs to produce raycasted first-person perspectives in the spirit of Wolfenstein 3D and Doom. The exercise is not about shipping a viable game. It is about understanding what a severely constrained, decades-old language can and cannot do when handed a fundamentally alien task — and what that constraint forces a developer to learn.

What Raycasting Is and Why It Still Matters

Raycasting is a rendering technique that casts one ray per vertical column of screen pixels from the player's viewpoint and calculates where each ray intersects with a wall or obstacle. Per Lode Vandevenne's widely referenced raycasting tutorial, the algorithm produces convincing pseudo-3D environments with a fraction of the geometry complexity that full 3D rasterization or path tracing requires.

id Software popularized the technique in Wolfenstein 3D (1992) and refined it in Doom (1993). Per Fabien Sanglard's retrospective code analysis, the Wolfenstein engine achieved acceptable frame rates on 386 and 486-class PCs precisely because raycasting's math is simple: per-column trigonometry, wall-distance calculations, and texture-height scaling. No z-buffer. No polygon sorting. One arithmetic pass per screen column.

That simplicity is what makes a COBOL port conceivable. The core loop is fixed arithmetic — exactly the computation profile COBOL was designed for, albeit in the context of ledger sheets rather than screen columns.

COBOL's Technical Constraints as a Game Engine

COBOL's design strengths introduce specific friction when applied to real-time graphics:

Modern COBOL standards reduce these obstacles materially. COBOL 2002 introduced FLOAT-SHORT and FLOAT-LONG IEEE floating-point types along with an expanded intrinsic function library, including FUNCTION SIN, FUNCTION COS, and FUNCTION ATAN. Per the GnuCOBOL documentation, implementations supporting the 2002 or 2014 standard can perform raycasting trigonometry natively — eliminating the hand-rolled lookup tables that dominated older COBOL graphics write-ups and that community discussions on Hackaday frequently cite as the primary debugging burden.

The practical implication: a COBOL raycaster written today against GnuCOBOL with -std=cobol2014 looks substantially cleaner than implementations written against COBOL 85.

Interfacing COBOL With Modern GPU Drivers

The most technically demanding aspect of a GPU-accelerated COBOL raycaster is bridging COBOL's memory model to a GPU compute API. AMD's ROCm stack (for RX 6000 and RX 7000 series GPUs on Linux) and NVIDIA's CUDA both expect a host language with pointer semantics, heap allocation control, and asynchronous dispatch — none of which map directly onto COBOL's DATA DIVISION model.

Hobbyist-documented approaches fall into four categories:

The pure-terminal approach is the most frequently documented starting point in community repositories. It avoids GPU driver complexity entirely, rendering colored character blocks to a terminal at whatever rate the emulator can redraw. For demonstrating that the raycasting algorithm works in COBOL, this is sufficient. For anything approaching a playable experience at higher resolutions, the SDL surface-blit or OpenGL shim paths are necessary.

It is worth noting that COBOL's CALL interface is well-specified and capable of invoking compiled C shared libraries. The mechanism itself is not exotic — the challenge is managing the data handoff between COBOL's typed data items and C's memory layout expectations, particularly for pixel buffer structures.

What Hardware Actually Matters

Because the bottleneck in a COBOL raycaster is almost always the CPU — specifically, the compiled fixed-point or floating-point arithmetic throughput of the inner ray loop — GPU selection has little bearing on pure-COBOL or terminal-mode implementations.

For hobbyists pursuing the GPU-accelerated path via a C shim, the hardware picture shifts:

AMD's RX 6000 series (RX 6600, RX 6700 XT) and RX 7000 series are most commonly referenced in Linux-based hobbyist GPU-shim projects because ROCm support for those architectures is well-documented under open-source toolchains — the same environment where GnuCOBOL is most mature. Performance in GPU-shim implementations is primarily gated by data transfer overhead between COBOL's framebuffer in system RAM and GPU memory, not by the GPU's peak shader throughput. Raycasting scenes are not GPU-bound by nature.

For the majority of COBOL raycaster projects — terminal mode at sub-fullscreen resolutions — a modern CPU with strong single-thread performance is the only meaningful hardware variable.

Development Experience and Debugging Reality

Community write-ups consistently identify debugging as the most time-intensive phase of COBOL graphics projects, for structural rather than algorithmic reasons:

No graphics-aware debugger. Standard COBOL tooling (GDB via GnuCOBOL's C backend, or cobcd) lacks frame visualization. Developers inspect pixel buffers as numeric arrays in WORKING-STORAGE rather than viewing rendered frames.

Legacy source format. COBOL's traditional FIXED column format restricts code to 72 columns and reserves specific column ranges for sequence numbers, area indicators, and data areas. GnuCOBOL's --free flag removes this restriction, but shared COBOL code frequently uses fixed format, requiring adjustment.

Lookup table construction in pre-2002 COBOL. Implementations targeting older COBOL standards must precompute sine, cosine, and arctangent values and store them in WORKING-STORAGE. Errors in these tables produce subtle rendering artifacts — skewed walls, incorrect texture heights — rather than crashes, making them difficult to isolate.

Framebuffer verbosity. Declaring a 320×200 pixel buffer in COBOL's WORKING-STORAGE SECTION requires explicit row-by-row or flattened item definitions. This is functionally equivalent to a C array declaration but occupies substantially more source lines, per GnuCOBOL community forum discussions.

GnuCOBOL's compilation-to-C backend enables GDB-level debugging with some configuration work, which developers in community threads report substantially reduces iteration time compared to interpreted COBOL environments.

Performance Expectations: COBOL vs. C Raycasters

Direct performance comparisons between COBOL and C raycasting implementations depend on compiler, optimization level, implementation quality, and target resolution. General framing from published benchmarking research is instructive:

Per the Computer Language Benchmarks Game, GnuCOBOL-compiled programs performing arithmetic-heavy work typically execute within the same order of magnitude as equivalent C programs under -O2 optimization. The performance gap is narrower than COBOL's reputation suggests for compute-bound workloads.

For raycasting specifically:

• Terminal mode at 80×24 characters: smooth output is achievable on any modern CPU; the bottleneck is terminal emulator redraw, not arithmetic speed
• SDL surface blit at 320×200: playable frame rates are achievable with GnuCOBOL native compilation and -O2 optimization
• High-resolution GPU-shim path: performance is determined primarily by the C shim's efficiency and GPU driver overhead, not COBOL's arithmetic speed

Specific framerate claims appearing in community write-ups and informal benchmark posts should be interpreted cautiously. Implementations vary widely in resolution, texture complexity, and the degree to which work has been offloaded to external libraries. No standardized COBOL raycasting benchmark suite exists as of mid-2026.

Community Context: Why These Projects Circulate

COBOL raycasters spread primarily through Hackaday, Hacker News, and Reddit's r/programming and r/gamedev communities, where they function as demonstrations of programmer creativity under artificial constraint rather than practical software engineering proposals.

The educational value, per recurring Hacker News discussion threads on constrained-language projects, lies in what the constraint forces the developer to confront: fixed-point arithmetic, lookup-table trigonometry, framebuffer management, and foreign-function interfaces — fundamentals that modern game engines and high-level languages abstract away. Building a raycaster in COBOL is a route to understanding how software graphics pipelines actually work at a lower level than Unity or Godot ever exposes.

This places COBOL raycasters in the same category as other constrained-environment programming exercises: Doom ported to calculators, Minecraft implemented in Excel, ray tracers written in SQL. The constraint is the point. The artifact proves the concept; the process builds the understanding.

For hardware enthusiasts, the takeaway is practical: if you want to experiment with a COBOL raycaster, your GPU is largely irrelevant until you commit to a C shim with explicit framebuffer handoff. Your CPU's single-thread speed and your Linux GnuCOBOL setup matter far more for the 90% of the project that lives in the ray loop itself.

Citations and sources

• Lode Vandevenne's Raycasting Tutorial — lodev.org
• Fabien Sanglard's Wolfenstein 3D Code Review — fabiensanglard.net
• GnuCOBOL Documentation — gnucobol.sourceforge.io
• Computer Language Benchmarks Game — benchmarksgame-team.pages.debian.net
• Hackaday — hobbyist project platform — hackaday.com

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.