Sega Genesis 3D Engine reaches 20 FPS with a full sprite background

A new Sega Genesis 3D engine update by developer Shannon Birt shows just how much performance developers can still squeeze from Sega’s 16-bit hardware. This isn’t a simple visual refresh. The latest build increases the size of the 3D display, adds a more detailed player ship, introduces Z-axis rotation and rewrites several parts of the rendering system. It also runs music and a sprite-heavy background at the same time. That’s a serious workload for a console launched in the late 1980s. The current demo averages around 20 frames per second. It does that while drawing polygons, moving large amounts of graphics data, playing music and controlling more than 100 background sprites. Nothing comes free here. Every extra effect uses processor time, memory or video bandwidth, so each improvement needs careful trade-offs elsewhere.

A new ship with almost twice the detail

The first change you’ll notice is the player ship. The earlier demo used a 23-triangle model inspired by the Arwing from Star Fox. This update replaces it with a custom spacecraft built from 39 triangles. That may sound tiny next to a modern 3D model, but on the Sega Genesis, 16 extra triangles make a real difference.

The Motorola 68000 processor has to transform every vertex, work out where each polygon belongs, handle clipping and prepare the image for display. The engine then needs to move the finished graphics into video memory before the next frame arrives. There’s no room for wasted work.

The new model shows that the engine can now handle more complex objects without collapsing under the extra load. Other low-polygon models are also being prepared for enemy ships, buildings and stage scenery.

The visual design has improved too. New striped structures, backgrounds and colour palettes give the demo a more consistent look. It’s beginning to resemble an actual game scene rather than a collection of isolated technical tests.

The 3D display is now 25%  larger

The internal rendering buffer has grown to 256 by 160 pixels, an increase of 25%. That extra vertical space matters more than the raw figures suggest. The player gets a wider view of the action, taller objects stay visible for longer and the whole scene feels less cramped. It’s a small resolution by current standards, but it suits the Genesis and gives the 3D graphics more breathing room. Getting it working wasn’t easy.

The engine already sits close to the console’s DMA transfer limit, even with an extended vertical blanking period. DMA lets the system move graphics data into video memory without making the main processor copy every byte manually, but the available transfer window is still limited. A nearly full frame can contain about 20 KB of data. That’s a lot to move in one go on this hardware.

To reduce the pressure, the engine now checks which tile rows have actually changed. It records the minimum and maximum affected lines, then sends only those sections to video memory. In many frames, this cuts the transfer size considerably.

There are still a few rough edges. When the rendered image uses almost the full height of the buffer, some flickering can appear near the top of the screen. The transfer system will need more tuning before that issue disappears completely.

Screen tilting adds a stronger sense of movement

The engine now supports Z-axis rotation. In plain terms, the whole view can tilt left and right as the ship moves. It’s a simple effect, but it makes turns feel much more convincing. The horizon shifts, the background reacts and the player gets a clearer sense that the ship is banking through the scene.

The processor cost stays relatively low because lookup tables handle much of the maths. This avoids four multiplication operations for each transformed vertex, which saves valuable CPU time. Even so, adding rotation exposed several problems in the existing renderer.

Drawing polygons is easier when the camera stays level. Once the view starts rotating, screen edges, clipping regions and polygon boundaries behave differently. Code that worked perfectly in a fixed view can suddenly draw the wrong pixels or miss parts of an object. The quad renderer had to be rewritten. The engine also uses different drawing routines depending on where an object appears.

Geometry that sits fully inside the screen uses a faster path without repeated boundary checks. Objects near the edge or close to the camera use a safer routine that checks for clipping. That way, the engine only pays the extra processing cost when it actually needs to.

The entire background is made from sprites

The background system takes a very unusual approach. Both of the Genesis background planes are used for the foreground 3D image. Together, they form a double-buffered rendering setup. While one plane appears on screen, the engine can prepare data for the other.

This makes graphics transfers much simpler and faster because the data can move into video memory in a mostly straight, linear sequence. The engine doesn’t need to spend as much time rearranging tiles. There’s one obvious problem.

With both background planes occupied, there’s nowhere left to draw the actual background scenery. The solution is to build the background entirely from sprites.

The system uses narrow 16-by-32-pixel sprites and a 114-sprite multiplexor to cover the display. The Genesis normally has strict sprite limits, but multiplexing allows the engine to reuse sprite slots across different parts of the screen. It’s a clever workaround.

Because the background consists of narrow sprite strips, each section can move independently. That lets the scenery tilt with the 3D view. Later versions may also add horizontal movement and a small amount of vertical scrolling. The engine still keeps a few sprites available for foreground effects, thanks partly to the console’s H40 display mode.

Music adds a more realistic performance test

The latest demo also runs music through the XGM1 audio driver. This matters because a silent technical demo doesn’t show the full performance cost of a real game. Music uses processor time, and that load has to run alongside rendering, input, object movement and graphics transfers.

The newer XGM2 driver was tested, but the heavy DMA traffic caused occasional audio slowdowns. XGM1 proved more reliable and continues playing at full speed, though it uses slightly more main CPU time. Together, the music system and sprite multiplexor take roughly 10 per cent of the available processor performance.

The developer has compensated by adjusting draw distances, object heights and rendering behaviour. The larger buffer also takes longer to fill, so the engine has to recover performance from several smaller optimisations rather than relying on one major speed increase. Despite all that, the demo still averages about 20 FPS.

That’s the key result. The engine now handles a larger image, better models, screen rotation, full music playback and a sprite-built background without losing its overall target performance. The technology is clearly moving beyond a basic test. The next step is turning these systems into proper levels, enemy encounters and more varied environments while continuing to improve frame rate, clipping and background movement.