SRB2 Rendering Errors

This page is a list of all common rendering errors in SRB2 and how to avoid them.

Hall of Mirrors

In SRB2, if one goes outside the level, a shimmering mass is visible in the empty space outside, composed of parts of previous frames of animation. The same effect can also be achieved by making unclosed sectors. This is called the Hall of Mirrors effect. The name comes from the fact that it appears somewhat like being in a hall of mirrors. It is sometimes abbreviated HOM or HOM Effect.

When SRB2 renders the level to the screen, it draws it into a buffer, an area of memory. During gameplay, the previous contents of the buffer are overwritten by consecutive frames. However, if a player travels outside the level, there are no walls to draw, so SRB2 draws nothing. Instead, the previous contents of the buffer are displayed, left over from previous frames.

If a player turns around and looks back toward the level, they can see through the walls and inside the level. The floors of the level stretch outwards toward the screen edge in vertical columns. This is because the SRB2 floor and ceiling drawing system is like a flood fill algorithm: because there are no walls to bound them, they simply "bleed" down to the edges of the screen.^[1]

Making overly large, high, and/or undetailed maps can cause this effect to happen as well. In the original Doom, it wasn't a problem, because a fracunit is a much more significant unit of distance for Doom than in SRB2. Nodebuilders like ZenNode don't often make much mistakes, but making your level too big will cause the nodes to be built incorrectly in certain places. This is why Botanic Serenity Zone experiences some visual glitches.

REDWALL

REDWALL is a special texture in SRB2. It can be used as a regular texture, but an invalid SkyNum in the level header will cause the game to render the sky as REDWALL.

File:Sample-redwallsky.PNG

Tutti-Frutti Effect

The tutti-frutti effect is a texture effect which can appear on walls. The texture is rendered distorted and there are often colors drawn which are not part of the original texture. These colors are the reason behind the name of the effect.

Tutti-frutti can be caused in four ways:

1. If a texture with transparent areas is used as an upper or lower texture on a two-sided wall, the content of the transparent areas is undefined. (By definition, the player can see the sector behind a wall only through the middle.) This is what happens if, for example, SPEC03 is used as a wall texture.
2. If a texture with transparent areas is used as the texture on a one-sided wall, the content of the transparent areas is undefined.^[1]
3. If a texture with transparent areas is used as the wall texture on an opaque FOF, the content of the transparent areas in undefined.
4. If a texture with transparent areas is used as the wall texture on a translucent FOF, it will still be translucent, but parts of the texture will be distorted.

File:Tuttifrutti-Software.PNG

Moiré Effect

SRB2's Moiré effect as shown on the farthest wall in this screenshot.

The Moiré effect is a buggy wall effect from the original Doom. Instead of the effect being triggered by going close to walls that were at least 560 fracunits high, it is triggered in SRB2 by viewing particular textures such as SPEC02 from a distance. As the player moves farther away from the wall or closer to the wall, the Moiré pattern on the wall changes.

Slime Trails

Slime trails, as they are called in the Doom community, are vertical bands of a flat (including F_SKY1) which "bleed" out towards the edges of the screen. They can occur when a level has not been built properly because of a bug in the nodebuilder, but they will also occur frequently as a natural consequence of SRB2's map format even in perfect nodebuilders. One of the times it can happen with ZenNode is when attaching sectors to the thok barrier provided that the thok barrier's floor height is below that of the sector it is attached to.

A screenshot of a "slime trail"

Within the map, vertex coordinates are only stored as integers. In normal map editing, vertices may only be placed at integer coordinates. During BSP building, however, lines may need to be split into segs at a location that has non-integral coordinates. The BSP builder ends up having to chop a significant amount of precision out of the coordinates of its generated vertices, and as a result, segs may end or begin far short of where they need to be placed for a mathematically correct BSP. This results in an open subsector, and the flat of the subsector will bleed out at the location of the offending vertex. Any open subsector will display similar behavior.

Slime trails are occasionally so severe that they span a large amount of the screen.^[1]

References