Re: Scalable games

["Stephen J Baker" <sjbaker@link.com>]

On Mon, 14 Oct 2002, Miguel A. Osorio wrote:

> 	I'm developing a 3D game engine myself and today I was discussing
> minimum hardware requirements for the game with one of the designers.
> Thing is, he asked me if we could make the engine make some decisions
> based on the current machine's performance, in order to improve
> efficiency. Things like, for example, if the engine works with discreet
> LODs for meshes, if the polygon count is running a bit high, why not cut
> off the more high detail levels and just work with the lower ones? This
> is, of course, a very simple example, but you should get the idea.
> 	The idea is to go beyond just switching features on and off and instead
> make the engine more aware of it's surroundings and thus more adaptable
> to changing workloads and running conditions. What do you think of this
> matter? What are your experiences or ideas for scalable engines?

A few years ago with older hardware (pre-hardware T&L) and simpler
rendering methods being used in games, this was quite do-able.
It was relatively easy to tell the difference between an overload
due to drawing too many polygons (which changing the level of detail
will help) and an overload due to hitting pixel fill capacity (which
has to be dealt with by reducing the number of rendering passes, or
something like that).

However, with hardware T&L and a much more tangled relationship
between per-polygon, per-pixel and per-state-change costs, it's
becoming impossible to know why you came close to not hitting your
target frame rate.  This can result in your code making dumb decisions
like grossly simplifying high-polygon-count objects when in fact that
doesn't make the slightest bit of difference to fill rate.

I think it's increasingly necessary to pre-profile the hardware on
program start-up by doing things like drawing a gazillion tiny
triangles (to measure the approximate polygon throughput) and a
few hundred full-screen sized polygons (to measure approximate
fill rate performance) and then using those numbers to tune the
model and rendering algorithms ahead of time.

Providing those are only setting defaults and you allow the user
to tune them in the 'Options' screen, that should be OK.  Remember,
some gamers live by 'twitch response' and need insanely high frame
rates whilst others may be enjoying the scenery and keenly observing
small details in the scene for clues to something or other.

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@link.com           http://www.link.com
Home: sjbaker1@airmail.net       http://www.sjbaker.org