Javier Castellar (javier++at++sixty)
Tue, 6 Feb 1996 11:14:48 -0800
Let me explain why your question is out of context ...
a) Resolution
First, doom is running at lower resolution that it seems to be. In fact is
under 200x200. If you scale up the image you will get a full 400x400 but the
actual rendering resolution is much lower. It means that you are running at
FOUR times the number of pixels.
b) Color resolution
On an Indy you are working on an full color resolution enviroment, which means
that you have much better color dynamic range.
b) Texture filter
The second issue is the type of filtering being used: in the Indy you are
running a nice MIPMPAP filter, with Z buffer ...etc. In Doom they are using a
much more gross texture filter (a few levels ...).
c) Hidden surface removal
Another issue is that they are using a video game oriented hidden surface
removal algorithm (a mixture between separate planes and a gross zbuffer). It
means that they avoid the fill rate limitation associated with a generic use of
Zbuffer but with they suffer LOTS of limitations in the database generation.
d) Clever tricks
They are using a long list of hardware dependent tricks that are very good but
are not generic enought to other type of application.
Anyway doom is a master piece and is plenty of tricks and techniques of people
that do not live in the inherent restrictions of a generic API. Using performer
in this way is also possible if you take advantage of the specific hardware
design of your system using gl/openGL callbacks. It also requires a strong
preprocessing of the database and a lot of "frame buffer oriented tricks".
I have seen people using performer and getting much better than Doom game
quality on an Indy system with fully textured rooms, fully animated entities at
30Hz/60hz at VGA resolution. Unfortunatelly few people use to extend performer
is this ways. I am talking about using the pixel transfer capabilities in
ogl/gl instead of the texture maping of gl/ogl.
If you are in the video game bussiness you have to use any hardware resource
that you can, which means that you cannot relay only on what the performer API
is giving to you. You need to extend the framework of the performer API with
the use of gl/OpenGL callbacks and your own custom design on the database to
get perfomance.
The comparison that you have made is too simplistic because words like
"textured" has a lot of different computational power meanings depending of the
filter being use (10-100x increase), and for the video game arena the filters
being used are far less computational expensive.
I may suggest the use of your own texture aproach, with no Z buffer and using
your own oclussion precalculation, and make full use of the amazing
pixel/framebuffer/memory operations available in the gl/ogl API.
P.D: I have been running a port of Doom on an Indy system one year ago with
better perfomance than on any PC system. This is becasue is a framebuffer
oriented game.
-Javier
-- ************************************************************************* * Javier Castellar Arribas * Email: javier++at++asd.sgi.com * * * Vmail: 3-1589 * * Member of Technical Staff * Phone: (415)-933-1589 | 933-2108 (lab) * * Applied Engineering * Fax: (415)-964-8671 * * Advanced Systems Division * MailStop: 8L-800 * ************************************************************************* * Silicon Graphics Inc. * * 2011 N. Shoreline Boulevard, * * Mountain View, California 94043-1386, USA * ************************************************************************* "Violence is the last refuge of the incompetant" Hari Seldon
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:22 PDT