Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Doom engine
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Rendering== {{unreferenced section|date=January 2012}} {{Original research section|date=February 2023}} ===Drawing the walls=== All of the walls in ''Doom'' are drawn vertically; it is because of this that it is not possible to properly look up and down. It is possible to perform a form of look up/down via [https://zdoom.org/wiki/Y-shearing "y-shearing"], and many modern ''Doom'' source ports do this, as well as later games that use the engine, such as ''[[Heretic (video game)|Heretic]]''. Essentially this works by moving the horizon line up and down within the screen, in effect providing a "window" on a taller viewable area. By moving the window up and down, it is possible to give the illusion of looking up and down. However, this will distort the view the further up and down the player looks. The ''Doom'' engine renders the walls as it traverses the BSP tree, drawing subsectors by order of distance from the camera so that the closest segs are drawn first. As the segs are drawn, they are stored in a linked list. This is used to clip other segs rendered later on, reducing overdraw. This is also used later to clip the edges of sprites. Once the engine reaches a solid (1-sided) wall at a particular x coordinate, no more lines need to be drawn at that area. For clipping the engine stores a "map" of areas of the screen where solid walls have been reached. This allows far away parts of the level which are invisible to the player to be clipped completely. The ''Doom'' graphic format stores the wall textures as [[row- and column-major order|sets of vertical columns]]; this is useful to the renderer, which essentially renders the walls by drawing many vertical columns of textures. ===Floor and ceiling=== The system for drawing floors and ceilings ("flats") is less elegant {{Says who|date=February 2023}} than that used for the walls. Flats are drawn with a [[flood fill]]-like algorithm. Because of this, if a bad BSP builder is used, it is sometimes possible to get "holes" where the floor or ceiling bleeds down to the edges of the screen, a visual error commonly referred to as a "slime trail".<ref>[https://doomwiki.org/w/index.php?title=Slime_trail&oldid=193418 Slime trail - The Doom Wiki]</ref> This is also the reason why if the player travels outside of the level using the [[Noclip mode|noclip cheat]] the floors and ceilings will appear to stretch out from the level over the empty space. The floor and ceiling are drawn as "visplanes". These represent horizontal runs of texture, from a floor or ceiling at a particular height, light level and texture (if two adjacent sectors have exactly the same floor, these can get merged into one visplane). Each x position in the visplane has a particular vertical line of texture which is to be drawn. Because of this limit of drawing one vertical line at each x position, it is sometimes necessary to split visplanes into multiple visplanes. For example, consider viewing a floor with two [[concentric]] squares. The inner square will vertically divide the surrounding floor. In that horizontal range where the inner square is drawn, two visplanes are needed for the surrounding floor. ''Doom'' contained a static limit on the number of visplanes; if exceeded, a "visplane overflow" would occur, causing the game to exit to DOS with one of two errors, "No more visplanes!" or "visplane overflow (128 or higher)". The easiest way to invoke the visplane limit is a large checkerboard floor pattern; this creates a large number of visplanes. As the segs are rendered, visplanes are also added, extending from the edges of the segs towards the vertical edges of the screen. These extend until they reach existing visplanes. Because of the way this works, the system is dependent on the fact that segs are rendered in order by the overall engine; it is necessary to draw nearer visplanes first, so that they can "cut off" by others further away. If unstopped, the floor or ceiling will "bleed out" to the edges of the screen, as previously described. Eventually, the visplanes form a "map" of particular areas of the screen in which to draw particular textures. While visplanes are constructed essentially from vertical "strips", the actual low level rendering is performed in the form of horizontal "spans" of texture. After all the visplanes have been constructed, they are converted into spans which are then rendered to the screen. This appears to be a trade off: it is easier to construct visplanes as vertical strips, but because of the nature of how the floor and ceiling textures appear it is easier to draw them as horizontal strips. ===Things (sprites)=== Each sector within the level has a linked list of things stored in that sector. As each sector is drawn the sprites are placed into a list of sprites to be drawn. If not within the field of view these are ignored. The edges of sprites are clipped by checking the list of segs previously drawn. Sprites in ''Doom'' are stored in the same column based format as the walls are, which again is useful for the renderer. The same functions which are used to draw walls are used to draw sprites as well. While subsectors are guaranteed to be in order, the sprites within them are not. ''Doom'' stores a list of sprites to be drawn ("vissprites") and sorts the list before rendering. Far away sprites are drawn before close ones. This causes some overdraw but usually this is negligible. There is a final issue of middle textures on 2-sided lines, used in transparent bars for example. These are mixed in and drawn with the sprites at the end of the rendering process, rather than with the other walls.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)