Doom rendering engine is
the core of the game engine which powers Doom and it’s sequels which is used as
a base to power other games using software licenses which is noted by Heretic,
Hexen and Strife. This was created by John Carmack with the auxiliary functions
which were written by John Romero, Dave Taylor and Paul Radek. Basically,
developed on NEXT computers, doom rendering engine was ported to Dos for Doom’s
initial release as well as the later ported to several other operating systems
and game consoles. The origin code for the Linux version of the Doom games
which was released to the public in 1997 under a license which was granted rights
to non-commercial use and again it was released under the General Public
License (GNU) in 1999. So, the result is that dozens of user-developed origin
ports have been originated that allow Doom to run on previously unsupported
operating system, oft fix bugs and sometimes radically spread the engine’s
functionally with new features.
Doom rendering engine is
not truly a 3D engine because it is not possible to look up and down clearly
and one sector cannot be placed above or beneath another. But, however it is a
fairly elegant system that allows pseudo 3D rendering. At the beginning, when
it was published, Doom was revolutionary and almost unique in its ability for
providing a fast texture-mapped 3D environment on contemporaneous hardware like
model 386 and early 486 PCs without specialized 3D graphics hardware running at
clock speeds around 25-33 MHz’s.
In spite of the simplicity and speed of the renderserver, doom rendering has some limitations. The basis render server lies on
16:16 fixed point numbers. With this type of limitations, the accuracy in small
units is lost since the limited precision hinders accuracy mainly while
multiplying and dividing. More graphical glitches cause of high resolutions
which is especially above the 5000 pixel resolution range, a few glitches
appear as field of view distortions along with floors and ceilings expanding
towards the horizon.
Doom engine renders the
wall since it traverses the BSP tree which is drawing subsectors by the order
of the distance from the camera. Since the frames are drawn, they are stored in
a linked list. It is used to clip other frames rendered later on which reducing
overdraw. The list is also applied later to clip the edges of sprites. In order
to reduce the burden on the engine’s performance that was essential back in the
early 90s while the game was developed and released, there is a fixed limit to
how many frames can be rendered at once, that is 256.
This excess frames are
not simply drawn which leaving visible gaps where wall should be and originating
a hall of mirrors effect but luckily as the order in which frames are drawn the
gaps are out in the distance where they are not more noticeable.
No comments:
Post a Comment