techinfo.txt

quake1 dos源代码最新版本

   the mode properly.  There may still be instances in which, due to VESA
   driver or hardware bugs, the machine will hang in certain modes;
   vid_testmode can't recover from these situations, but it can recover
   from a blank or scrambled screen.

vid_wait <wait type>
  sets the type of waiting that the video adapter should do, as follows:
  0: no waiting
  1: wait for vertical sync active
  2: wait for display enable active

The default state of vid_wait depends on the video mode selected.
(_vid_wait_override can force vid_wait to 1, wait for vertical
sync; see the description of _vid_wait_override below.)
In built-in modes 0-10, the default is always 0, no waiting.  You
can set vid_wait to 1 (wait for vertical sync) to eliminate shear
and tearing in these modes (so partially-completed frames are never
drawn, resulting in a rock-solid image).  However, waiting for
vertical sync can result in substantial performance loss.

In VESA modes, if the adapter is VGA compatible and there's enough
memory for three video pages, then triple-buffering is enabled and
vid_wait is set to 2, wait for display enable.  There is little
performance loss to this sort of waiting.  If the adapter is not
VGA compatible, or if there's only enough memory for double-buffering,
then vid_wait is set to 1 (wait for vertical sync).  This can cause
significant loss of performance, but some sort of wait is generally
necessary to avoid occasional glitching of the screen when
page-flipping; we always choose the lowest-cost wait option that
seems to be safe to use.  If there's only enough memory for one
page, or if vid_nopageflip 1 is in effect, then vid_wait is set to 0
(no wait).  As with modes 0-10, vid_wait 1 can be used to eliminate
shear, but at a performance cost.

We have encountered problems with a few adapters in VESA modes when
vid_wait is set to 2 (wait for display enable).  Apparently some adapters
just toggle display enable all the time, rather than only when pixels
are being sent to the screen; this can cause occasional glitches in
which the screen image jumps for one frame.  You can fix this by
setting vid_wait to 1 (wait for vertical sync).  We would have made
vid_wait 1 the default, but it's slower, and vid_wait 2 works on most
machines.

The default setting for vid_wait can be changed from the console
at any time.  If you are in a VESA mode that waits for vertical
sync and want to turn it off to get a speed-up, you can do so.
However, changing a vid_wait 1 default in a VESA mode may result
in problems.  If vid_wait defaults to 1 (wait for vertical sync)
in a mode, and you force it to 2 (wait for display enable), the
machine may hang, because some VGA-incompatible adapters, such as
some ATI Mach64s, don't support the display enable status.  If you
force vid_wait to 0 (no wait), then the screen may glitch periodically
if the page flips at a time that results in a bad flip address,
although some adapters work fine with no wait at all.

If you force a new setting for vid_wait and encounter problems, DO
NOT send us a bug report!

_vid_wait_override <1|0>
	can be used to force wait for vertical sync in all modes.  When
    _vid_wait_override is set to 0, the type of waiting, if any, for
    each video mode that's set thereafter is automatically set to
    what appears to be the fastest safe state.  However, it is
    possible in some cases that automatic setting may result in some
	screen glitching, and it is also true that shear can be
    eliminated by waiting for vertical sync (although at a cost in
	performance), so it may be desirable in some cases to override
    the automatic wait selection and always wait for vertical sync.
    This can be done by setting _vid_wait_override to 1.  Once set,
    this remains in effect through all succeeding mode sets, even
    when Quake is exited and re-entered; the only way to keep Quake
    from waiting for vertical sync once _vid_wait_override is set to
    1 is to set _vid_wait_override to 0.  Note that changing
    _vid_wait_override doesn't affect the current mode, but rather
    takes effect on the next mode set.  _vid_wait_override is initially
    set to 0.

_vid_default_mode <mode #>
    can be used to force Quake to start up in a particular mode.
    The easiest way to select a default mode is by pressing the
    'D' key in the Video Modes menu, but you can alternatively
    use _vid_default_mode to specify the mode in which you want
    Quake to start up in future Quake sessions.  _vid_default_mode
    is initially set to 0.


Higher-quality perspective texture mapping
------------------------------------------

For maximum speed, perspective correction is performed only every 16
pixels.  This is normally fine, but it is possible to see texture ripples
in surfaces that are viewed at sharp angles.  For more precise texture
mapping, set the console variable d_subdiv16 to 0.  Doing this will result
in somewhat slower performance, however, and the difference in visual
quality will not normally be noticeable.


Known video problems and workarounds
------------------------------------

If you think you've encountered a bug, see "Bug Reporting," below.
As a general rule, go back to mode 0 if you have problems; mode 0
should work properly in all cases.

On some ATI Mach64 adapters, the palette is sometimes too dark in
some VESA modes, and is tinted oddly (too red, for example) in other
modes.  The workaround is to use different modes, or modes 0-10.

In modes 0-10, shear and tearing can occur as partially finished
frames are displayed.  Workaround:  set vid_wait to 1 (wait for
vertical sync); this can result in a substantial performance loss,
however.  An alternative is to use a page-flipped VESA mode.

In page-flipped VESA modes, occasional glitched frames may occur with some
VESA driver-hardware combinations.  Workaround:  set vid_wait to 1 (wait
for vertical sync) (you can set _vid_wait_override to 1 to make waiting
for vertical sync permanent for future Quake sessions), or use a different
mode.

The VESA video drivers that come with some video adapters don't
support low-resolution modes such as 320x200; often,
nothing lower than 640x400 is supported.  For example,
this is the case with some ATI adapters.  There's nothing
Quake can do to provide low-resolution VESA modes in these
cases, because Quake simply supports whatever modes the VESA
driver chooses to report as supported.  Unfortunately, 640x400
is too high a resolution for really good performance unless you
have a very fast Pentium or a Pentium Pro, so on machines with
this sort of adapter, the VESA modes aren't very usable.
Workaround:  Use UniVBE 5.2, which supports low-resolution modes
on a wide variety of adapters.  Note that a few adapters simply can't
support low-resolution modes, in which case you'll have to stick with
the low-resolution VGA and Mode X modes that are built into Quake,
which run fine but may be somewhat slower than VESA modes.

A few video adapters are almost but not fully VGA compatible, because
they don't support some unusual VGA video modes.  In particular, a few
adapters don't support the 360-wide Mode X-style video modes that are
build into Quake (modes 2, 4, 6, 8, and 10), and display garbage in those
modes.  Workaround:  use different modes, such as 0, 3, 5, 7, 9, or any
VESA modes that are available.

Under Win 95, the palette occasionally gets messed up when switching from
Quake to the desktop and back again.  You can restore the palette by
bringing down the console (either press tilde ('~'), or press Esc to bring
up the menu, select Options, and select Console... from the Options menu),
and typing bf and pressing the enter key, to generate a background flash,
which sets the palette.  Press Esc to exit the console.  Alternatively,
setting the screen brightness, either from the Options menu or via the
gamma console variable, sets the palette.

Under Win 95, if the system key (the key with the Win 95 flag on it) is
pressed while Quake is running fullscreen in a VESA mode, Win 95 may be
unable to switch back from the desktop to Quake, in which case it will
notify you of this, then terminate the Quake session.  This is a quirk
of Win 95, and normally there is no workaround other than not to press
that key or not to use VESA modes.  (Some people go so far as to remove
the system key from their keyboard.)  However, you can
disable the system key for Quake with the following utility:

http://www.microsoft.com/windows/download/doswinky.exe

Switching away from Quake with Alt-Enter, Ctrl-Esc, Alt-Tab, or
Alt-Spacebar all work fine (except that if you disable the system key
with doswinky.exe, Ctrl-Esc will also be disabled).


Performance
-----------

Quake's graphics should be adequately fast in mode 0 (320x200) on all
Pentium-class machines. If you feel Quake is running slowly, set the
showturtle console variable to 1; you will then see a turtle icon
appear in the upper left corner of the screen if the frame rate drops
below 10 frame/second.  If you are getting the turtle, you are probably
not getting great gameplay.  Performance can be improved in several ways:

* size down the screen with the minus key

* select a lower-resolution mode, if possible

* use a VESA mode

* if you're using a VESA mode and vid_wait is set to 1 (wait for
vertical sync) by default (you can check by typing vid_wait<enter>
in the console), you can try setting vid_wait to 0 or 2, as detailed
in the discussion of the vid_wait command above.  Be aware that
risks of screen glitching or hung machines are associated with
overriding a default vid_wait 1 setting in VESA modes.

To see how exactly fast Quake is running, bring up the console and type

host_speeds 1<enter>

You will see a display at the top indicating total frame time in
milliseconds, and also server, graphics, and sound frame time in
milliseconds.  (Note, though, that unless you also do

snd_noextraupdate 1<enter>

sound time will actually show up as graphics time.  However,
snd_noextraupdate 1 can cause sound to get choppy, so it's not
generally recommended.)

Lower numbers are better.

Type

host_speeds 0<enter>

to turn off the frame time display.


Pentium Pro Performance
-----------------------

The Pentium Pro is a very fast Quake platform, but has one weak spot; it is
by default very slow on writes to video memory.  This means that in default
hardware configurations, you are usually much better off setting
vid_nopageflip to 1 if you use VESA modes, so drawing is done to system
memory instead of to video memory.  Remember that you must set the mode
after setting vid_nopageflip to 1 in order to get vid_nopageflip to take
effect.  (vid_nopageflip can sometimes be faster on a Pentium, too, but
not by nearly as much in general, and it's often slower.)

The Pentium Pro has some special features that are not turned on by default,
but which can help Quake performance a LOT.  These features can be enabled
by John Hinkley's program FASTVID, which can be obtained from
ftp://members.aol.com/JHinkley/fastvid.zip.  Performance in 640x480
mode on a Pentium Pro/150 nearly doubled after FASTVID was run; Quake
was very playable (and looked great!) at this resolution.

There's the usual caution with FASTVID:  It could conceivably make your
system run goofily, or who knows what.  FASTVID is not a product of
id Software, and id makes no guarantees regarding FASTVID. In other words,
use FASTVID at your own risk.

************************************************************************
IMPORTANT NOTE: FASTVID works only on Pentium Pros!!!  Please do NOT
contact either John Hinkley or id with problems concerning FASTVID on
Pentium or 486 machines.
************************************************************************


Video Bug Reporting
-------------------

If you encounter a video-related bug, please fill out the form found at the
end of this file and e-mail it to [e-mail].  There are several
problems that are not bugs, and shouldn't be reported, including:

* unavailability of some VESA modes; VESA modes are only supported by
Quake if they are 8-bpp, are LFB modes (except for 320x200), and are
no greater than 1280x1024 in resolution.  If you have a VESA mode
that doesn't seem to be working properly, please contact the
manufacturer; we just use the information that the VESA driver
provides us with.

* problems that occur when you change vid_wait from a default value
of 1 (wait for vertical sync) in VESA modes

* sluggish performance on 486s

* the known palette problem on some Mach64s.

* the known palette problems switching from fullscreen to the desktop and
back under Win95.

* the known problems switching back from the desktop in VESA modes after the
system (Windows flag) key has switched from fullscreen to the desktop.

* video modes that are not listed in the Video Modes menu, or that are not
listed or are listed with "**" in the output from vid_describemodes; such
modes are either not supported by your video adapter, or cannot be supported
by Quake in the amount of memory your system has.  High-resolution modes will
often not be available in 8 Mb systems.

* 360-wide video modes that don't work although other resolutions do work

* lack of low-resolution VESA modes; the availability of low-resolution modes
is the responsibility of the VESA driver.  UniVBE 5.2 provides low-resolution
modes on most adapters.

Apart from these, we would very much like to hear about any video
problems you encounter.


==========================================
==     Sound Subsystem Documentation    ==
==========================================

Quake's sound subsystem works only with Sound Blaster compatible sound
cards.  For Quake to get the correct settings for DMA channel and PORT
address, you must set your BLASTER environment variable (or have it set for
you with the DIAGNOSE utility in your SB16 directory).  If you do not have
the BLASTER environment variable set, your sound will not work.  If your
sound card supports Sound Blaster compatibility, Windows 95 should set this
variable for you.

Note:  some sound cards do not have 100% Sound Blaster compatible
hardware, but emulate the Sound Blaster interface.  Such cards may
display some inconsistencies relative to an actual sound blaster.
In particular, sound may be delayed on some cards.

Note:  it is possible for sound to get choppy if the frame rate
drops to a very low level, below 5 frames a second.  A frame rate
that low will not provide a good gameplay experience, so if you
do experience choppy sound, your machine is almost certainly not
fast enough to run Quake satisfactorily in general.

If (when) you see bugs, please use the form attached to the end
of these docs to submit a bug report.

Sound Card Command Line Options, Commands, and Variables
==================================================================

The commands and variables below work under any operating system.
Command-Line options are typed on the command line in most any place
but only in operating systems which support command line interfaces,
like DOS's COMMAND.COM, or NEXTSTEP's or Linux's csh, sh, or bash.
For example, under DOS, the NOSOUND option would be used like this:
"C:> quake -nosound".