[WIP] Mimas Engine: my take on hardware-rendered Saturn Doom (make a WAD, get a Saturn FPS)

[N0rt0N85]

Hi all I'm Romain (N0rt0N85). I'm building Mimas Engine, a Doom port for the Saturn that actually leans on the hardware, running here on real hardware (Phoebe ODE).

▶️

The idea: The infamous 1997 Saturn Doom was a pure software renderer that ignored the VDP1/VDP2 (Carmack vetoed Jim Bagley's hardware engine, and later called it a mistake). Mimas Engine is my shot at the hardware-accelerated Saturn Doom that never shipped, and because it's a real Doom engine, the content is just a WAD: drop in a vanilla / limit-removing WAD and you have your own FPS on real Saturn hardware, no Saturn code required.

Under the hood

• doomgeneric / Chocolate-Doom core, rendered across both SH-2 CPUs (slave-CPU column/visplane renderer with work-stealing).
• VDP1 hardware walls (distorted sprites) + VDP2 hardware sky and floor;
• Big WADs stream from the CD with no RAM cart : Doom II / Ultimate / Plutonia / TNT and the community WADs hopefully !
• Built on SRL, thanks @ReyeMe, it made this genuinely pleasant (basically a flagship SRL demo).

Status: WIP, playable on hardware at low FPS. Targets vanilla / limit-removing WADs (Chocolate-Doom compat, not GZDoom/ZScript).

Credits. Engine = doomgeneric/Chocolate-Doom; the texture cache is ported from d32xr; the VDP1 approach is inspired by Lobotomy's SlaveDriver/PowerSlave (my renderer diverges with hybride world (vdp1, vdp2, sh-2). Big respect to Fafling too, Mimas is a different, ground-up take (hardware rendering + big-WAD engine) rather than a patch of the retail binary.

I'll keep this thread as a dev-log and will publish videos on this youtube playlist;
Happy to dig into any technical questions.
Feedback very welcome!

Romain

 

[TrekkiesUnite118]

Not to discount the work on this engine, but it should be noted that Retail Saturn Doom doesn't use a software renderer. It uses VDP1 to render everything but the sky and HUD layers which are handled by VDP2. It's a straight port of PS1 Doom and has the 3D scenery drawn using 1px high strips on VDP1. So it is very much a hardware renderer using the Saturn hardware. The reason it runs poorly is because it's rushed and sloppy with little optimization.

Hexen on the other hand does use a software renderer for the 3D scenery.

 

[N0rt0N85]

Not to discount the work on this engine, but it should be noted that Retail Saturn Doom doesn't use a software renderer. It uses VDP1 to render everything but the sky and HUD layers which are handled by VDP2. It's a straight port of PS1 Doom and has the 3D scenery drawn using 1px high strips on VDP1. So it is very much a hardware renderer using the Saturn hardware. The reason it runs poorly is because it's rushed and sloppy with little optimization.

Hexen on the other hand does use a software renderer for the 3D scenery.

I see, my knowledge on the topic was far from complete, then! Thanks for the clarification 🙂 !
I guess I can review my hopes down for the final performances :/

 

[N0rt0N85]

2026-07-01 changelog:

• Dynamic sky/floor horizon: the sky always meets the floor now (no gap); the hardware floor is clipped below a per-view horizon.
• Dual-SH2 plane work-stealing via the SH-2 TAS instruction (Fafling-style meet-in-the-middle), default-on, smoother frame pacing.
• 3-player mode: the empty 4th quadrant now shows a player-position minimap.
• Perf: removed a per-frame 131 KB floor re-upload; memory tidy-ups.
• Hardware sky/floor in split-screen views.
• The debug overlay is toggled on/off in this one so you can see the clean view.

 

[TrekkiesUnite118]

I see, my knowledge on the topic was far from complete, then! Thanks for the clarification 🙂 !
I guess I can review my hopes down for the final performances :/

I wouldn't get your hopes down too much. There's plenty of evidence that the Saturn can handle Doom both in its retail configuration and in a pure software rendering setup. Fafling has gotten retail Doom up to about PS1 levels of performance with code improvements, and Doom Resurrection on the 32X shows even a lower clocked dual SH2 setup can run software rendered Doom at a good framerate.

 

[fafling]

Not to discount the work on this engine, but it should be noted that Retail Saturn Doom doesn't use a software renderer. It uses VDP1 to render everything but the sky and HUD layers which are handled by VDP2. It's a straight port of PS1 Doom and has the 3D scenery drawn using 1px high strips on VDP1. So it is very much a hardware renderer using the Saturn hardware. The reason it runs poorly is because it's rushed and sloppy with little optimization.

Hexen on the other hand does use a software renderer for the 3D scenery.

Saturn Doom does software render the flats and uses VDP1 to accelerate the mixing of that rendering with the walls and sprites which are fully rendered by VDP1.

 

[slygamer]

2026-07-01 changelog:

• Dynamic sky/floor horizon: the sky always meets the floor now (no gap); the hardware floor is clipped below a per-view horizon.
• Dual-SH2 plane work-stealing via the SH-2 TAS instruction (Fafling-style meet-in-the-middle), default-on, smoother frame pacing.
• 3-player mode: the empty 4th quadrant now shows a player-position minimap.
• Perf: removed a per-frame 131 KB floor re-upload; memory tidy-ups.
• Hardware sky/floor in split-screen views.
• The debug overlay is toggled on/off in this one so you can see the clean view.

Cool project from everything I am seeing so far. Have you considered taking a look at GitHub - dgrubb/DoomFS2: A WIP port of DOOM to the Sega Saturn.. I found it a while ago and wonder if any code in it, might help. Otherwise, i wish you the best of luck.

 

[N0rt0N85]

Cool project from everything I am seeing so far. Have you considered taking a look at GitHub - dgrubb/DoomFS2: A WIP port of DOOM to the Sega Saturn.. I found it a while ago and wonder if any code in it, might help. Otherwise, i wish you the best of luck.

Thanks for the support ! Yes, I have found the github, but didn't check it deeply yet.
There are many references, projects or trials around Doom to look into (DoomFS2, D32XR, FastDoom, Fafling saturn patch...). I keep them at hand, and check them on need (to compare, find solution to my issues, or optimize).
It's one of the reason I started this port: get inspiration from the numerous other projects on a well documented engine (and make myself suffer by adapting it on Saturn). I thought it would be a nice way to learn the hardware architecture and its limitations: I'm trying to document my findings on the way.

Seeing all the (INCREDIBLE !) work done by the saturn dev community (and segaxtreme in particular) in the past years got me motivated to commit to this POC for the last weeks. I'm not sure where this is going, but it's a childhood / teenage dream I'm fullfilling: building something for the Sega Saturn.

 

[ROS]

Keep on Dooming.

 

[N0rt0N85]

Solo

New

• VDP1 walls: partially-occluded walls (below a nearer floor / above a deported ceiling) stay on the VDP1 instead of falling back to software — texel-aligned world-anchored cut + software wedge
• VDP1 player weapon (prio-7 layer, default ON): offloads the weapon fill to hardware, HW flicker fixed (the tearing you see in the video is fixed now)
• World enemies on the VDP1: sprites offloaded to hardware with occlusion vs walls, tear-safe texture cache (~78% reuse), and an adaptive budget that scales with VDP1 headroom
• Décrochage border fill: motion gaps at floor/ceiling silhouette edges filled with the plane's own color instead of showing sky
• Textured VDP1 floors (experimental, gated / off by default): world-tile textured floors built on the slave SH-2 — not the default, not a net perf win yet, shipped for A/B only

Perf / cleanup

• Removed redundant plane zero-fills → −6 to −8 ms on HW (all floor modes)
• HUD blit skips the static band when the HUD is idle (~14% less copy)
• Render toggles refactored into 2 axes (M = offload mode, SQ = software quality) + slave aux-job API

Failed / parked

• Below-floor & near-wall VDP1 clamps → squished / warped → reverted to CPU
• Enemies on VDP1 in shareware → fires cleanly but can't move the frame (~1 fps ceiling, present-bound) → parked as a Doom II horde lever
• Blit DMA (bus-bound) and M5 BSP staging (neutral) → no win; dead SCU-DMA scaffolding removed

Multi

New

• Software sky-wrap fix in split views + per-branch baked HW floor
• VDP1 player weapon (prio-7 layer, default ON): offloads the weapon fill to hardware, HW flicker fixed
• World enemies on the VDP1: sprites offloaded to hardware with occlusion vs walls, tear-safe texture cache (~78% reuse), and an adaptive budget that scales with VDP1 headroom
• 4th-quadrant minimap in 3-player with player positions
• [Ugly] Compact 3/4p HUD band → view shrunk to 160×96 (~14% fewer pixels per quadrant)
• Status bar restored when returning to 1p after a split; dangling-sector fix on level reload

Failed / parked

• 2-player HW floor via RPB dual-param → ~10 HW builds, black/smear → settled-negative (needs a cell-mode floor, impossible on the current bitmap floor)

Big vanilla WADs

New

• All Doom 2 maps load
• CD streaming improvements

 

[slygamer]

@N0rt0N85, you are making such great progress so far and so quickly, and well done so far on what you have implemented.

At a later date, once you get it into a more stable state, would you be planning on releasing the engine code on github?
To that end, do you believe it would be possible to import other Doom based games like Hexen, Heretic, Strife: Quest for the Sigil?

I am interested to hear your thoughts on this and best of luck 🙂

 

[N0rt0N85]

@N0rt0N85, you are making such great progress so far and so quickly, and well done so far on what you have implemented.

At a later date, once you get it into a more stable state, would you be planning on releasing the engine code on github?
To that end, do you believe it would be possible to import other Doom based games like Hexen, Heretic, Strife: Quest for the Sigil?

I am interested to hear your thoughts on this and best of luck 🙂

Thanks so much, that really means a lot 🙂

On releasing the code: yes, absolutely. The game core actually already lives publicly on GitHub here. It's not stable, finalized or cleaned yet.
doom-saturn-core is a lightly-patched doomgeneric/Chocolate-Doom with the dual-SH2 column renderer, kept as its own repo so my Jo Engine port (my previous try, pure software) and this SRL one can share it. Mimas, the embarrasing one , is the SRL/Saturn platform layer (VDP2 framebuffer, sound, pad, CD WAD streaming). The goal has always been for this to be open and reusable.

On other Doom-engine games: great question, and the answer really splits by how far each game strayed from vanilla Doom:

• Heretic: the most realistic. It's essentially the Doom engine with the same map format, no scripting VM, no polyobjects. Mostly a matter of the extra actors/weapons and content fitting in RAM. This is the natural "next one."
• Strife: engine-wise close to Doom (same map format), but it adds dialogue/quest/conversation systems and a lot more content, so it's more about memory and scope than rendering.
• Hexen: the hard one. It's the Raven branch: Hexen map format, the ACS scripting bytecode VM, polyobjects, and the hub save-state system. That's real extra engine code and a much bigger RAM footprint (hubs keep map state resident).

The encouraging part: the rendering approach isn't the obstacle for any of them. Fun fact: the official Hexen Saturn port did all its 3D in software straight into the VDP2 framebuffer with VDP1 only handling sprites, which is exactly the architecture I'm using here. So the path is proven; the real wall is the Saturn's 2 MB of RAM, especially for Hexen's hubs. On a bare console (no RAM cart) I'd expect Heretic to be very doable, and Hexen to be the ambitious stretch goal.

Thanks again for the kind words and the great question!