Changes

From DoomWiki.org

Polyobject

60 bytes added, 16:55, 11 September 2009
m
Source port implementations: 9303
== Source port implementations ==
The [[ZDoom]] [[source port]] also implements polyobjects, but prefers the use of thing types 9300, 9301, and 9302 to those used by Hexen so as to avoid editor number conflicts with [[Doom]] and [[Strife]] (for example, 3001 is also used by the [[Imp]] and the [[Reaver]]). It also adds a third type of polyobjects (9303) which hurt hurts 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 [[ZDBSP]].
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. Like ZDoom and for the same reason, Eternity supports the editor numbers 9300, 9301, and 9302 for polyobject anchors and spawn points, and support for ZDoom's new type (9303) was added in r851.
== References ==
7,722
edits