Game porting is fundamentally constrained by hardware architecture, not just CPU specifications; the Neo Geo's 2D sprite-based system with no bitmap graphics mode and CPU unable to directly access cartridge graphics data makes Doom's 3D rendering impossible, despite sharing the same Motorola 68000 CPU as other systems that successfully run Doom.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
DOOM Runs On Everything...except Neo GeoAdded:
It seems like a common thing that every piece of tech out there has a port of Doom. This is because the code is elegant, fast, modular, and runs on just about everything. Even systems that came before Doom have ports, and some ports have had help thanks to custom hardware like the original Doom on the SNES. Doom is written in very clean and elegant CC code. It's not difficult to learn and follow along. It doesn't use any modern language updates, nor does it rely on anything that's depreciated, and it compiles up rather nicely. It's also Indianfriendly, which is very important for portability. So, I think it's fair to say that it's a bit of a surprise that the Neo Geo has never seen a port of Doom. After all, the Neo Geo shares the same microprocessor CPU, the Motorola 68000, as the Sega Genesis and the Commodore Omega, both of which have seen aftermarket versions of Doom running on their respective hardware.
But on the Neo Geo, it's nowhere to be found.
Many developers who've worked on the Neo Geo have often said that Doom is near impossible to run. But the question now is why? Why would the Neo Geo be impossible to run a port of Doom? After all, it has a video display, a CPU, RAM, and all the things to run a video game.
So, let's go ahead and dive in as to the reasons why. Now, the Neo Geo runs a Motorola 68,000 at 12 MHz. It has 64 kilob of RAM, 84 kilob of VRAM, and 2 kilob of sound memory. Its graphics display runs at 320x224 resolution with a total of 340 oncreen colors out of a pallet of 65,000. This alone sounds like it would be an uphill challenge for Doom, but we've seen Doom running on all matters of hardware. So, let's move on. The problem is that the Neo Geo is a 2D spritebased hardware beast, and sprites is exactly what the Neo Geo uses to render its display. The system draws its sprites in vertical strips of tiles which are 16x6 pixels in size with a limitation of 96 sprites per scan line and it's possible to have sprites as large as 16x 512 pixels. Like the AmIgga, the Neo Geo has no bit map graphics mode. That is to say, there is no direct way to read and write pixels to and from display memory. But we've already seen Doom running on the Omega.
So how is this possible? Now on the AmIgga, graphics could be drawn on screen into chip memory by writing values to the Omega's bit planes and a conversion known as chunky topler is used in Doom ports to the AmIGGA to convert the bit map data that Doom outputs to its frame buffer into a suitable format that the Omega can display. This process is quite slow and it's one of the reasons that you need a pretty fast 030 or higher accelerated Omega to run Doom on. This alone puts the Neo Geo at a serious disadvantage because the hardware is fixed. It's not feasible just to drop a more powerful processor on the motherboard. But the strength of the Neo Geo is 2D. There is no concept of 3D line drawing or vector graphics at all. Even before games like Doom, the AmIgga had games such as Star Glider 2 by Argonaut, many flight simulators, and many 3D vector-based games. The Omega's Blitter hardware can draw lines and fill them relatively quickly. In comparison, all the Neo Geo has is 2D sprites. Now, a few Neo Geo games tried to simulate real-time 3D, such as Viewpoint and the Super Spy, but in reality, these were all precomputed sprite data stored in the Neo Geo's cartridge. The Super Spy simulates a firsterson environment by using a feature of the hardware known as sprite shrinking. shrinking, which is also known as scaling, reduction, and zooming, is a hardware feature which allows sprites to be scaled down with pixel perfect accuracy in both dimensions. In fact, many games use this feature, and it's a key visual of the Neo Geo that gives it its own unique style and charm. Fighting games would often zoom in and out in sync with the gameplay to extend that feeling of immersion, and it was a pretty cool effect. Now, so far we've said things that really wouldn't stop a Doom port from running on the Neo Geo. There must be a way to work around this. But I think the biggest challenge overall is the fact that the 68,000 CPU has no direct access to the graphics data on any Neo Geo cartridge. And this is an architectural fact that many people overlooked. The CROM, which contains the sprite graphics, is wired directly to the LSPC video chip, but it's not on the 68000's address bus. This means that the CPU cannot sample any data directly from the CROM. It can't sample any texture data. It can't read a pixel. It can't do anything with the graphics data. The only thing it can do is write references such as tile numbers, positions, and shrink values into VRAMm to let the video chip fetch the actual pixels from CROM by itself. And this is a significantly different architecture than a frame buffer machine or even on the AmIgga with its bit planes where it can read and write pixels freely. So even if we consider a software renderer, the Neo Geo simply cannot do it. it can't read source graphics and there's no frame buffer to write the results into. So now it was time for a challenge. Okay, let's assume that Doom is off the table. Or maybe we need to start simpler. Can we draw or render a simple raycaster that something like Wolfenstein 3D uses on the Neo Geo?
Would that be possible? We did say that the Neo Geo draws everything using sprites and the sprite is made up of little images which are 16x6 pixel tiles that are stacked into a vertical strip.
So the Neo Geo's approach is to maintain a list of sprites and their positions and properties in a special memory region. And this hardware renders this list every single frame. We also said that the Neo Geo can shrink any sprite independently in X and Y for free. So, in theory, it would be possible to build a raycaster where each wall slice is a shrunk sprite. A raycaster screen is built from vertical strips. For each column on the screen, you can cast a ray into the world, find where the wall hits, measure the distance, and draw a vertical line whose height depends on distance. And with enough granularity, the brain registers this as a 3D scene.
So, I did end up building a simple raycaster on the Neo Geo. And the way it works is that we have 80 sprites side by side, each four pixels wide, sitting at a fixed X position across the screen.
With every frame, we leave the X value alone. And what we're doing is we're altering the vertical Y shrink position.
The walls appear to move and change with you, but we're not drawing anything. All we're doing is adjusting 80 shrink values. Now, with any raycaster, we have a 2D grid of one and zero values. one designating a wall and zero designating as empty. The player has two values, a position and a facing direction. For each of the 80 screen columns, we simply ask, if I shoot a ray from the player out to the world in the direction that a column represents, what wall cell does it hit first and how far away is it? And this is what the rendering function does. It ray marches 80 times per frame and fills three arrays. the shrink values for each column, the Y position for each column, and the color pallet value for each column.
So, at this point, we have everything in an array of values. But there's still nothing rendering to the screen. Now, the next thing that we need to do is call our blit function, and this is where we write our shrink values, our X and Y positions, and sprite values to the SCB or the sprite control block.
Now, for visibility, I also added a 2D mini map on top, and I used the Neo Geo's fix layer to do this. Now, the fixed layer is meant for text and HUD elements such as score and lives, and it always draws on top of the sprites. It's much less flexible, but it's perfect for a 2D mini map. And this is the final result. It's not too bad. Every single frame, we read the joystick and move the player. And for each of those 80 screen columns, we march array through the grid map until it hits a wall and then measure the distance that turns into a height and color. Then we stream those 80 height and positions and colors into the sprite control block where each column is a single textured sprite that shrinks to the right height. We leverage the Neo Geo scaling to do the actual work for us. There's no frame buffer, no pixel drawing, and certainly no floating point. Now, a few things to note here.
This is far from optimized code. It's something that I put together very, very quickly and it runs probably at about 8 frames pers. We could definitely get performance to be a lot better. But as it stands, we're running this under emulation as well. I have not tested this on real hardware, though I don't think it would be any different. And for those who are interested, I've left the source code in the description below.
Feel free to check it out as you need to.
So with this simple proof of concept, I do think that it is possible to build a Wolfenstein style engine to run on the Neo Geo one that uses full height vertical strips. But I do agree that Doom is probably not feasible on the Neo Geo. Walls are no longer uniform height strips. In Wolfenstein, every wall is the same height and aligned to a grid.
So, a column is always one texture strip top to bottom, which is scaled. In Doom, there are things like sectors that have arbitrary floors and ceiling heights.
You get things like ledges, staircases, raised platforms, elevators, tunnels, and windows that you can look through into rooms beyond. So, we're no longer talking about scaled strips. We would need several independently positioned, independently scaled sprites per column, and they would have to be clipped against each other. There's also the concept of diagonal walls. In Wolfenstein, walls are grid aligned.
That is, every wall faces exactly north, south, east, and west. In Doom, walls sit at any angle, and a single screen column crossing a diagonal wall sees the wall surface at a continually varying distance down the column. So on the Neo Geo, it would be very difficult, if not impossible, to apply a per pixel varying scale and perspective map of one sprite.
Diagonal walls need exactly that. So even a single diagonal wall would be difficult to map as a hardware scaled strip. Other things such as floor and ceilings are also a big problem. In the raycaster, floors and ceilings are flat colored regions. In Doom, floors and ceilings are textured and perspective mapped. Doom also had sectorbased lighting per pixel via color maps. In our raycast caster, we can do things like banded pallet shading per column, which works well. But with Doom's lighting, which varies within a surface and across floor pixels, the Neo Geo must swap pixels per sprite, but it cannot remap per pixel across a textured plane. And this is before we're talking about sprites, enemy monsters, weapons, all the other stuff that makes Doom what it is. and assuming you found a way to solve for all this having all this running on a 12 MHz CPU. Now, I'm smart enough to tell you that I don't want to say it's impossible because as soon as you say something is impossible, the gauntlet has been thrown down. But I do think the only way that Doom can run on the Neo Geo is with some extra hardware.
But that of course is just my opinion with hacking a raycasting program that runs on a Neo Geo with unoptimized code.
So, we're going to leave it here for today's episode. I do hope you enjoyed this look at the reasons why Doom seems like an impossibility on the Neo Geo.
Now, I say seems like a impossibility because later this year sees the release of the Neo Geo AES Plus, which will reinvigorate the homebrew community all over again. And maybe someone out there who has the right skills could potentially bring us doom to the Neo Geo. I think there is some possibility that it could come. But for now, we are going to leave it here for today's episode. I do hope you enjoyed it. Thank you so much for watching. And if you liked it, leave me a thumbs up. And we will catch you guys in the next episode.
Bye for now.
Related Videos
OpenHuman VS Hermes AI: Who Wins?
JulianGoldieSEO
285 views•2026-05-29
Long-Running Agents — Build an Agent That Never Forgets with Google ADK
suryakunju
142 views•2026-05-30
5 Mind Blowing Omni Uses Cases
PaulJLipsky
1K views•2026-06-02
This computer is made from real human brain cells. And you can buy it.
Talktmsmedia
3K views•2026-05-28
BREAKING: Microsoft’s New Image Generating Model Beat Out GPT 1.5 and Nano Banana 2
aimmediahouse
122 views•2026-06-03
I Made the Same Anime Fight Scene in Every AI Video Generator
NobleGooseAnime
295 views•2026-05-30
Nvidia Bets Big On AI PCs | New Chip To Power Windows Laptops | Technology | AI Updates | N18S
cnnnews18
3K views•2026-06-01
I Tested NEW Opus 4.8 on Four Projects (Updated LLM Leaderboard)
AICodingDaily
298 views•2026-05-29











