Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Initial conversion to markdown

Browse source
This commit is contained in:
James Gregory 2013-12-30 17:51:31 +11:00
commit 5e10794a24
362 changed files with 67353 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

124
70-09.md Normal file
View file

@ -0,0 +1,124 @@
------------------------ --------------------------------- -------------------------
[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