124 lines
7.2 KiB
Markdown
124 lines
7.2 KiB
Markdown
------------------------ --------------------------------- -------------------------
|
||
[Previous](70-08.html) [Table of Contents](index.html) [Next](appendix-a.html)
|
||
------------------------ --------------------------------- -------------------------
|
||
|
||
Also, the moving sky texture will probably be gone or will change. One
|
||
likely replacement is an enclosing texture-mapped box around the world,
|
||
at a virtually infinite distance; this will allow open vistas, much like
|
||
Doom, a welcome change from the claustrophobic feel of Quake.
|
||
|
||
Another likely change in Quake 2 is a shift from interpreted Quake-C
|
||
code for game logic to compiled DLLs. Part of the incentive here is
|
||
performance—interpretation isn’t cheap—and part is debugging, because
|
||
the standard debugger can be used with DLLs. The drawback, of course, is
|
||
portability; Quake-C program files are completely portable to any
|
||
platform Quake runs on, with no modification or recompilation, but DLLs
|
||
compiled for Win32 require a real porting effort to run anywhere else.
|
||
Our thinking here is that there are almost no non-console platforms
|
||
other than the PC that matter that much anymore, and for those few that
|
||
do (notably the Mac and Linux), the DLLs can be ported along with the
|
||
core engine code. It just doesn’t make sense for easy portability to
|
||
tiny markets to impose a significant development and performance cost on
|
||
the one huge market. Consoles will always require serious porting effort
|
||
anyway, so going to Win32-specific DLLs for the PC version won’t make
|
||
much difference in the ease of doing console ports.
|
||
|
||
Finally, Internet support will improve in Quake 2. Some of the
|
||
QuakeWorld latency improvements will doubtless be added, but more
|
||
important, there will be a new interface, especially for monitoring and
|
||
joining net games, in the form of an HTML page. John has always been
|
||
interested in moving as much code as possible out of the game core, and
|
||
letting the browser take care of most of the UI makes it possible to
|
||
eliminate menuing and such from the Quake 2 engine. Think of being able
|
||
to browse hundreds of Quake servers from a single Web page (much as you
|
||
can today with QSpy, but with the advantage of a standard, familiar
|
||
interface and easy extensibility), and I think you’ll see why John
|
||
considers this the game interface of the future.
|
||
|
||
By the way, Quake 2 is currently being developed as a native Win32 app
|
||
only; no DOS version is planned.
|
||
|
||
### Looking Forward {#Heading21}
|
||
|
||
In my address to the Computer Game Developer’s Conference in 1996, I
|
||
said that it wasn’t a bad time to start up a game company aimed at
|
||
hardware-only rasterization, and trying to make a game that leapfrogged
|
||
the competition. It looks like I was probably a year early, because
|
||
hardware took longer to ship than I expected, although there was a good
|
||
living to be made writing games that hardware vendors could bundle with
|
||
their boards. Now, though, it clearly is time. By Christmas 1997, there
|
||
will be several million fast accelerators out there, and by Christmas
|
||
1998, there will be tens of millions. At the same time, vastly more
|
||
people are getting access to the Internet, and it’s from the convergence
|
||
of these two trends that I think the technology for the next generation
|
||
of breakthrough real-time games will emerge.
|
||
|
||
John is already working on id’s next graphics engine, code-named Trinity
|
||
and targeted around Christmas of 1998. Trinity is not only a
|
||
hardware-only engine, its baseline system is a Pentium Pro 200-plus with
|
||
MMX, 32 MB, and an accelerator capable of at least 50 megapixels and 300
|
||
K triangles per second with alpha blending and z-buffering. The goals of
|
||
Trinity are quite different from those of Quake. Quake’s primary
|
||
technical goals were to do high-quality, well-lit, complex indoor scenes
|
||
with 6 degrees of freedom, and to support client-server Internet play.
|
||
That was a good start, but only that. Trinity’s goals are to have much
|
||
less-constrained, better-connected worlds than Quake. Imagine seeing
|
||
through open landscape from one server to the next, and seeing the
|
||
action on adjacent servers in detail, in real time, and you’ll have an
|
||
idea of where things are heading in the near future.
|
||
|
||
A huge graphics challenge for the next generation of games is level of
|
||
detail (LOD) management. If we’re to have larger, more open worlds,
|
||
there will inevitably be more geometry visible at one time. At the same
|
||
time, the push for greater detail that’s been in progress for the past
|
||
four years or so will continue; people will start expecting to see real
|
||
cracks and bumps when they get close to a wall, not just a picture of
|
||
cracks and bumps painted on a flat wall. Without LOD, these two trends
|
||
are in direct opposition; there’s no way you can make the world larger
|
||
and make all its surfaces more detailed at the same time, without
|
||
bringing the renderer to its knees.
|
||
|
||
The solution is to draw nearer surfaces with more detail than farther
|
||
surfaces. In itself, that’s not so hard, but doing it without popping
|
||
and snapping being visible as you move about is quite a challenge. John
|
||
has implemented fractal landscapes with constantly adjustable level of
|
||
detail, and has made it so new vertices appear as needed and gradually
|
||
morph to their final positions, so there is no popping. Trinity is
|
||
already capable of displaying oval pillars that have four sides when
|
||
viewed from a distance, and add vertices and polygons smoothly as you
|
||
get closer, such that the change is never visible, and the pillars look
|
||
oval at all times.
|
||
|
||
Similarly, polygon models, which maxed out at about 5,000 polygon-model
|
||
polygons total—for all models—per scene in Quake, will probably reach
|
||
6,000 or 7,000 per scene in Quake 2 in the absence of LOD. Trinity will
|
||
surely have many more moving objects, and those objects will look far
|
||
more detailed when viewed up close, so LOD for moving polygon models
|
||
will definitely be needed.
|
||
|
||
One interesting side effect of morphing vertices as part of LOD is that
|
||
Gouraud shading doesn’t work very well with this approach. The problem
|
||
is that adding a new vertex causes a major shift in Gouraud shading,
|
||
which is, after all, based on lighting at vertices. Consequently,
|
||
two-pass alpha lighting and surface caching seem to be much better
|
||
matches for smoothly changing LOD.
|
||
|
||
Some people worry that the widespread use of hardware acceleration will
|
||
mean that 3-D programs will all look the same, and that there will no
|
||
longer be much challenge in 3-D programming. I hope that this brief
|
||
discussion of the tightly interconnected, highly detailed worlds toward
|
||
which we’re rapidly heading will help you realize that both the
|
||
challenge and the potential of 3-D programming are in fact greater than
|
||
they’ve ever been. The trick is that rather than getting stuck in the
|
||
rut of established techniques, you must constantly strive to “do better
|
||
with less, in a different way”; keep learning and changing and trying
|
||
new approaches—and working your rear end off—and odds are you’ll be part
|
||
of the wave of the future.
|
||
|
||
------------------------ --------------------------------- -------------------------
|
||
[Previous](70-08.html) [Table of Contents](index.html) [Next](appendix-a.html)
|
||
------------------------ --------------------------------- -------------------------
|
||
|
||
* * * * *
|
||
|
||
Graphics Programming Black Book © 2001 Michael Abrash
|