SRB2 Rendering Errors

From SRB2 Wiki

1 Hall of Mirrors
2 REDWALL
3 Tutti-Frutti Effect
4 Moiré Effect
5 Slime Trails
6 References

Hall of Mirrors

Hall of Mirrors caused by going outside the level.

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]

Hall of Mirrors in Botanic Serenity Zone caused by the nodebuilder.

If a wall texture is missing, Software will render it as if it were invisible. In most cases, this will cause Hall of Mirrors to occur. OpenGL, on the other hand, will replace a missing wall texture with REDWALL.

Making overly large, high, and/or undetailed maps can cause this effect to happen as well, sometimes even in OpenGL. 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 in Software Rendering.

REDWALL

REDWALL is a special texture in SRB2. It can be used as a regular texture, but in OpenGL rendering, it is also the texture that replaces missing textures that are needed by the game. Moreover, an invalid SkyNum in the level header will cause the game to render the sky as REDWALL in both Software and OpenGL.

Having REDWALL in a level due to missing textures will always hurt the visuals of the level. Preventing it is simple:

SRB2 Doom Builder has an option that checks for missing textures.
Software Rendering simply renders missing textures as being invisible. Therefore, people who test custom maps exclusively in Software Rendering may not see that there is a missing texture. Testing in OpenGL, however, will display the REDWALL.

Types of REDWALL
An example of REDWALL accidentally left in a map due to the creator testing exclusively in Software Mode.	An example of REDWALL sky caused by an invalid SkyNum.

Tutti-Frutti Effect

The tutti-frutti effect is a texture effect which can appear on walls in Software Rendering. 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:

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.
If a texture with transparent areas is used as the texture on a one-sided wall, the content of the transparent areas is undefined.^[2]
If a texture with transparent areas is used as the wall texture on an opaque FOF, the content of the transparent areas in undefined.
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. This sometimes can cause Hall of Mirrors in OpenGL.

OpenGL does not exhibit the tutti-frutti effect; instead, using textures in such a manner will cause the sky to appear as a flat in the inside of the sector.

Tutti-Frutti Rendering
The tutti-frutti effect as shown in Software Mode.	The sky flat glitch as shown in OpenGL Mode.

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. However, in OpenGL mode with the filter set to Trilinear, this effect does not occur.

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" in Botanic Serenity Zone.

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.^[3]