Editing Visplane overflow
From DoomWiki.org
Your changes will be displayed to readers once an authorized user accepts them. (help) |
Warning: You are not logged in. Your IP address will be recorded in this page's edit history.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
The '''visplane overflow''' (often abbreviated to '''VPO''') is a fatal error that occurs in [[vanilla Doom]] when there are more than 128 unique floor and ceiling surfaces (''visplanes'') on the screen simultaneously. | The '''visplane overflow''' (often abbreviated to '''VPO''') is a fatal error that occurs in [[vanilla Doom]] when there are more than 128 unique floor and ceiling surfaces (''visplanes'') on the screen simultaneously. | ||
− | Laying out a floor in a checkerboard pattern of alternating floor textures is the simplest way of triggering a visplane overflow. The demonstration level {{idgames|file=levels/doom/g-i/gridwad|title=GRID1212.wad|linkonly=1}} from April 1994 contains the earliest documented example of this (along with correspondence with id reporting the problem), although in earlier versions of the engine a [[hall of mirrors effect]] was triggered instead of a crash. | + | Laying out a floor in a checkerboard pattern of alternating floor textures is the simplest way of triggering a visplane overflow. The demonstration level {{idgames|file=levels/doom/g-i/gridwad.zip|title=GRID1212.wad|linkonly=1}} from April 1994 contains the earliest documented example of this (along with correspondence with id reporting the problem), although in earlier versions of the engine a [[hall of mirrors effect]] was triggered instead of a crash. |
[[BSP (node builder)|BSP v2.2]] added features to detect and prevent visplane overflows, by changing how [[subsector]]s are laid out. It used a heuristic which was based on guesses about the true causes of visplanes, and which was tested against actual [[WAD]]s, in some cases positively identifying the exact location the player would need to be to cause a visplane overflow. When the exact cause of visplane overflows was found and fixed -- after the release of the Doom source code -- BSP v3.0 removed the code which attempted to guess about them, and left only the code which helped prevent them from affecting earlier versions of Doom. | [[BSP (node builder)|BSP v2.2]] added features to detect and prevent visplane overflows, by changing how [[subsector]]s are laid out. It used a heuristic which was based on guesses about the true causes of visplanes, and which was tested against actual [[WAD]]s, in some cases positively identifying the exact location the player would need to be to cause a visplane overflow. When the exact cause of visplane overflows was found and fixed -- after the release of the Doom source code -- BSP v3.0 removed the code which attempted to guess about them, and left only the code which helped prevent them from affecting earlier versions of Doom. |