Rendering errors

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

Hall of mirrors

The hall of mirrors effect as seen when going outside the boundaries of a level.

The hall of mirrors effect, sometimes abbreviated as HOM, is a visual error that occurs in Software rendering when the game tries to render a wall that has no valid texture. In the place where the missing texture should be, parts of the game's previous animation frames will be displayed, causing an appareance that is similar to a hall of mirrors. The same effect can be observed when going outside the level boundaries with the use of the noclip command.

This effect occurs because the Software renderer uses a buffer to store the visual information that is drawn to the screen. In each new animation frame, the contents of the buffer are overwritten with new information and then drawn to the screen. If an area of the screen has no valid texture that can be drawn, the game will write nothing into the buffer for that area. This means that whatever was previously in the buffer will be drawn instead. The OpenGL renderer uses a different method for drawing to the screen and therefore does not exhibit the hall of mirrors effect.

The console variable homremoval can be used to change the drawing behavior for missing textures: homremoval no displays the usual effect, homremoval yes fills all areas with missing textures with a solid black color, and homremoval flash will cause these areas to flash with a red color, which can be useful for spotting missing textures.

REDWALL/REDFLR

An example of a REDWALL sky caused by setting an invalid sky number.

REDWALL and REDFLR are a texture and corresponding flat in SRB2 that consist merely of a solid red color. SRB2 replaces unknown textures and flats with REDWALL and REDFLR respectively. Additionally, if the SkyNum parameter of a level header refers to an invalid sky, REDWALL will be used as the sky instead.

Tutti-frutti effect

The tutti-frutti effect as it appears on a solid wall with a partially transparent texture.

The tutti-frutti effect occurs in Software rendering when a texture that contains transparent pixels, such as SPEC02, is used on a wall that is not meant to be transparent. Doing this will cause the texture to appear distorted and the transparent areas to be filled with colors that are not part of the original texture. These colors are what give the tutti-frutti effect its name. To avoid the tutti-frutti effect, partially transparent textures should only be used as middle textures on two-sided linedefs. They should not be used on one-sided linedefs, on FOFs, or as upper or lower textures on two-sided linedefs. In OpenGL rendering, the tutti-frutti effect does not occur and the transparent areas are rendered correctly on any surface.

Moiré effect

The Moiré effect as seen on the walls of 2.1:Castle Eggman Zone Act 2.

The Moiré effect is a visual error that causes a Moiré pattern to appear on a wall, which changes its appearance according to the camera's distance to the wall and the viewing angle. The effect typically occurs when viewing textures with small repeating patterns, such as DC1 and MARIO4, from far away. In this situation, the patterns of the texture become so small that they fill less than one pixel on the screen. This leads to an effect called aliasing, which causes patterns to appear that are not in the original texture, in this case the Moiré pattern. Aliasing can be removed with trilinear texture filtering, which can enabled in OpenGL rendering with the gr_filtermode console variable.

Slime trail

An example of a slime trail.

A slime trail is a part of a flat that stretches out vertically across the screen. The name originates from an occurrence of the effect in the first level of Doom, where a small part of a slime flat would stretch out to the bottom of the screen. The effect occurs when rendering an unclosed sector or subsector. The reason for this is that the Doom engine uses a flood fill algorithm to draw flats: The flat of a sector is first drawn across the entire screen and then cut off where it intersects with the sector's boundaries. In an unclosed sector, there is a gap in the boundaries where the flat is not cut off, causing it to extend towards the edge of the screen.

While unclosed sectors can (and should) be avoided by the mapper, unclosed subsectors are often created by a nodebuilder due to rounding errors and cannot always be avoided. For example, in Doom's map format, vertex coordinates are stored as integers, so vertices may only be placed integer coordinates. When building the BSP tree, however, the nodebuilder will occasionally need to split a linedef into segments at a non-integer map coordinate. In this case, a vertex is inserted at the nearest integer coordinate, resulting in a small gap between the vertex and the segments it is supposed to connect. This will cause the associated subsector to be unclosed, leading to a slime trail.

Slime trails also caused by ZenNode when attaching a sector to a thok barrier whose floor height is below that of the sector it is attached to.