Changes

From DoomWiki.org

Polyobject

140 bytes added, 20:21, 28 May 2009
m
Source port implementations: ZDoom implementation
== Source port implementations ==
The [[ZDoom]] [[source port]] also implements polyobjects, but prefers the use of thing types 90009300, 90019301, and 9002 9302 to those used by Hexen (the numbers used by Hexen conflict so as to avoid editor number conflicts with [[Doom]] and [[Strife]] (for example, 3001 for example being is also used by the [[Imp]] and the [[Reaver]]). It also adds a third type of polyobjects (9303) which hurt on simple contact. The ZDoom implementation of polyobjects is otherwise nearly functionally identical to that in Hexen, including the inherent limitations on location and motion. Glitches in rendering that can be caused when polyobjects cross node lines (and thus overlap with static geometry or into adjacent subsectors) can be partially but not entirely abated by use of a so-called "polyobject-aware" node builder, which includes the popular [[zdbspZDBSP]].
The [[Eternity Engine]] completed implementation of a dynamic seg rendering system which splits polyobjects through the BSP to generate subsector-contained fragments, in a system similar to how some true 3D engines deal with models and complex moving objects. This not only completely eliminates the need for a polyobject-aware node builder, but also allows any number of polyobjects per subsector and arbitrary motion of polyobjects between subsectors with reasonably similar properties. Eternity is currently capable of allowing use of polyobjects inside Doom-format maps via the use of [[ExtraData]], and will also support them in the Hexen and [[UDMF]] map formats when support for those formats has been finalized.
7,722
edits