Difference between revisions of "VQuake"

Revision as of 09:34, 24 February 2013

VQuake is a version of Quake written specifically for the Rendition Verite V1000 accelerator. It works quite differently than GLQuake because the V1000 has unique strengths and weaknesses. It is based upon the Quake software renderer.

Architecture

A usenet posting by former Rendition programmer Stefan Podell describes in detail how VQuake works in addition to why it is not optimal for V2x00.

Posted by Stefan Podell on October 30, 1997 at 04:34:56:

Okay, with my reputation tarnished by VQuake and VHexen2
not going any faster on the V2x00, I'm here to explain 
why this is the case.

First, the VQuake/VHexen2 engine can be roughly broken 
down into four parts (actually, most games are like 
this):

* Software setup of geometry commands
* Software creation of texture maps
* Transfer of textures and commands to the renderer
* Rendering

The first two parts are totally CPU dependent, the 
third is bus dependent, and the fourth, in my case,
is Verite dependent.

Now, some history on the design of VQuake.

When we first started working with Id on accelerated
Quake, Id's design was much like their design for Quake
2: that there would be a "driver" part of the code,
somewhat separated from the "main" game. (In Quake's
case, though, since it is a DOS game, this would be
accomplished with different executables rather than the
more elegant DLL model employed by Quake 2.) 

They had two 3D engine paths through the game. One was 
a traditional triangle/polygon based engine, which is
what they predicted all 3D accelerators would use, and
one was a fairly elaborate "span sorting" scheme which
the software renderer used.

So we set out accelerating the game using the polygon
interface. It looked great with filtering, but it
wasn't terribly fast. Even after doing polygon sorting
on the world polygons and turning off the Z buffer for
those, the performance was not great. (You must 
remember that the V1000 wasn't really designed to do
Z-buffering as its primary rendering style.) So Walt
Donovan, then with Rendition, and Michael Abrash, then
with Id, talked about using the software engine's span 
interface. 

For those who are interested, there have
been a few articles published by Michael on the guts
of the engine. I think Dr Dobb's Journal had the best,
most detailed one. To the best of my understanding,
the engine sorts all world surfaces (floors, walls,
ceilings, and sky) on each scanline of the screen, 
and keeps track of the edges of each span. When it
goes to draw a particular surface (polygon), it is
then guaranteed that every pixel it is drawing is the
only world pixel that will be drawn at those 
coordinates. (This is hard to explain...) Suffice to
say that when the world surfaces are drawn, exactly
the minimum possible number of pixels is drawn (i.e.,
a depth complexity of 1). Meanwhile, the Z buffer
has been filled with the correct Z values, but Z
comparison is not necessary, since we know the depth
complexity is one. Next, when we start drawing objects
(monsters, weapons, etc), we turn on the Z comparison
so that the objects are properly hidden by the world.

The reasoning behind this was that the Pentium was
pretty slow at drawing pixels, but fast at floating
point operations. By doing more of what the Pentium
was good at, Quake was able to do less of what the
Pentium was bad at. Overall, a performance win, with
the side benefit of allowing much more interesting 
scenes.

((((whew))))

Walt and Michael decided that since the Verite 1000
wasn't terribly good at Z-buffered pixels, that if
we let the Pentium take care of this span sorting, we
could reduce the number of pixels the Verite would 
draw. Furthermore, we'd be able to turn off the Z
compare function on the Verite. So now, rather
than having a depth complexity of around 1.5 
(about 450000 pixels at 640x480) pixels that draw
at the peak rate of about 10MP/s on the V1000, we
had a depth complexity of 1 (300000 pixels) that 
draw at a peak rate of about 17MP/s.

As with the software renderer, we could then turn on
the Z compare and draw all the more interesting 
objects. Yes these pixels would be as slow as always,
but there are generally far fewer of them.

So we set out writing new microcode to support Quake's
span data format. When we finally got this working,
sure enough, the performance was way better than the
original polygon-style engine.

Back to my four-part description of Quake's engine, we
traded more CPU work in stage one for less Verite work
in stage four, which ended up getting us a big win.

Note that when you increase the vertical resolution in
the game, the engine must sort more scanlines. And if
you increase the resolution in either direction, the
renderer must draw more pixels.

Also note that when Quake was written, P133's were 
pretty top-notch, and the software frame rates were
low enough that the span sorting was adequate to
keep up. With the Verite rendering much faster than
the Pentium could, suddenly the span sorting was the
bottleneck. It wasn't until we got to P200's that 
the Verite was busy most of the time.

So whether you're on a V1000 or V2x00, the CPU has
a lot of work to do.

Okay, that's part one.

Part two is texture maps. (This will be much shorter.)
The way the software renderer in Quake works is to take
a small texture tile (like a couple of bricks) and
duplicate it into a larger texture map for the world
surface while it is applying the light map (dynamic or
static). It then caches that texture map and draws 
with it. When it needs to draw that surface again, it
checks to see if the lights have changed (like when 
you fire a weapon). If they have, it must regenerate
the texture map and recache it.

The VQuake engine does the same thing, with the extra
step of having to download the texture map to video 
memory.

Quake also mipmaps these surfaces. The mipmap level
is chosen based on the size of the polygon (in pixels)
relative to the size of the texture map.

In VQuake, the texture cache is kept in video memory
along with the display buffers and Z buffer. The
quick equation for how much memory the display and Z
buffers take is Width * Height * 6 (3 buffers, each
16-bits deep). The rest is for texture maps (minus
about 128K for microcode).

So when you increase the resolution, two things 
happen that increase the demands on the CPU for
texture map generation. First, you have less texture
memory, so textures will fall out of the cache more
often, requiring regeneration. Second, higher 
resolution mipmaps will be chosen, further straining
the texture cache.

The assembly code for generating the textures is
darn near as good as it can be. I certainly can't
think of any instructions to remove, and Michael
Abrash, who wrote it, is a genius at this stuff.

We considered doing two pass lighting on the Verite,
but after some experiments decided the CPU could do
it faster.

So again, no matter the Verite chip, the CPU will be
very busy. (The texture mapping, by the way is the
primary reason that timedemo works so much better as
a real benchmark than timerefresh. In the demo
sequences, there's lots of combat going on, which
pushes the system much harder.)

Alright. That's part two.

Part three is the bus. As you know, the currently
available Verites use the PCI bus, and are able to
use DMA asynchronously, which does not use the 
CPU. The bus activity will steal some cycles from
the CPU, but not an appreciable amount.

Simple enough.

Finally, the renderer. The V2x00 chips are *much*
faster at drawing than the V1000. The fastest the
V1000 could go was 25MP/s. The V2100 goes 40MP/s 
and the V2200 goes 50MP/s. Adding features (Z,
alpha, fog, etc.) would slow the V1000 down a lot,
while having minimal impact on the V2x00 chips.

So I understand why people were expecting VQuake
and VHexen2 to go much faster on the V2x00. But
the fact of the matter is that a faster renderer
doesn't necessarily buy you much given the
architecture of this engine. And because of that,
we're working on a V2x00-specific version of the
engine, to take advantage of the extra pixel 
power, while lightening the load on the CPU.

I must admit that I was beginning to wonder if
my beliefs about the engine's behavior were 
really true. So I just did a weird hack on
VHexen2 to test something:

I put in a check at the time drawing commands
and texture maps are sent to the Verite to see
if the game was in "timedemo mode". If it was,
I just threw away the commands and continued.
Then, when timedemo was over, drawing would
kick back in and I would see the results. The
purpose of this was to simulate an *infinitely
fast* renderer and bus (something we'd all
like to have :-) (This is also known as a 
"speed of light" test.)

==============================================
Here are the results of running timedemo demo1
on my current VHexen2 build (beta 3 candidate).
I ran all the tests at 320x200, 512x384, and
640x480, with antialiasing set to 0 and to 7
at all resolutions.

The first three tests are with rendering turned
on, in other words, the numbers everyone has
been responding to so far. The last set of
numbers is my "infinitely fast" renderer.

(fps are antialias = 0/antialias = 7)

The first test was on my P166MMX (64MB RAM) 
with my V1000 reference board, which runs at 
the same speed as an Intergraph 3D 100.
(These seem slower to me than what I 
remember, but I can't find where I wrote 
down my old numbers, so I just re-ran
these.)
=====================
320x200 (51.0 / 43.1)
512x384 (26.7 / 24.2)
640x480 (16.9 / 15.5)
=====================

Next, the same PC with a V2200. The first
thing you'll notice is that it's a little
slower at low resolutions. I think this is
because the span microcode has a little extra
overhead on the 2200. It also doesn't
currently interleave buffers. I'm looking 
into fixing those things.
=====================
320x200 (48.1 / 41.9)
512x384 (32.9 / 28.5)
640x480 (22.0 / 20.1)
=====================

Next, a V2200 in a P2-300 (this computer has
a pretty sucky hard drive in it and 32MB RAM,
so there was more swapping going on than
on my 166MMX)
=====================
320x200 (71.0 / 63.4)
512x384 (43.3 / 36.1)
640x480 (27.9 / 23.5)
=====================

And finally, my P166MMX with my "infinitely
fast" renderer/bus test
=====================
320x200 (56.0 / 48.2)
512x384 (44.1 / 37.8)
640x480 (32.4 / 29.7)
=====================

So you can see that at low resolutions, a 
faster CPU gets you much more by way of 
performance than a faster renderer. And as
resolution increases, infinitely fast 
rendering is a good thing :-)

Again, all this adds up to us working on 
a V2x00 version of this engine. We'll tell
you more as we know more about its progress.

This is not to say that there's no room for
improvement in my current version of the 
game. So if I figure out any cool way to make
this go faster on a V2x00, I'll definitely
put it in. There is one thing Quake 2
does that I want to try in VHexen 2. I'll 
let you know.

Regards,
Stefan (maybe I should use a .plan file) Podell

_________________________________________________

Readme

This VQuake release is a small upgrade.  Everything in whatever previous
readme you have is probably still true.  This release simply adds one new
setting.

r_surfacelookup (default 1, enabled)

Disabling r_surfacelookup will make the CPU perform the 8 to 16 bit
conversion step for texture maps instead of the Verite.  On faster CPUs
this can increase performance.  Results also depend on what resolution
you choose.  In other words, your mileage may vary.


*********

NiNe's notes:

Installation:

1) Put "VQuake.exe" and "VQ95.bat" into your \Quake directory.
2) If you have a V1000, put "spd3d.uc" into your \Quake directory.
3) If you have a V2x00, put "spd3d.uc2" into your \Quake directory.
4) Run "VQuake.exe" or "VQ95.bat".

	    Welcome to the Verite port of Quake!

--- Quick Start

	Copy vquake.exe, spd3d.uc, and vq95.bat to your quake 
directory (the one that contains quake.exe.) If you already
have vquake.exe or spd3d.uc, make sure the new version
overwrites the old one.
	Type "vquake" to run the accelerated game. Use vq95.bat 
when running Windows95 to allow TCP/IP networking.

	NOTE: you *MUST* upgrade your software Quake from 1.01
to 1.06 before running vquake 1.07. You can get the patch file
from id software at http://www.idsoftware.com/dlquake.html.

-- beta 5
	fixed bug where aa particles disappeared after a while

-- beta 4
	folded in id's 2/6 release, which fixes at least the
	grappling hook bug (bad entity number)

	Also, if you get a page fault while running vquake, try
	replacing cwsdpmi.exe with the new version in cwsdpmi3.exe.
	Rename the old one to some different name, and then rename
	the new one to cwsdpmi.exe. This has worked for at least
	one person.

-- beta 3
	Fixed bugs:
	alias models get completely wrong textures sometimes (but now
		requires 20Mb minimum to run under windows.)

	some alias model mipmaps show a blue fringe.

	timerefresh under water is amusing.

	weird scanlines generated by some models.

	hardly any particles get drawn.

	if no soundblaster in dos, will hang.

	antialiased particles are in (see r_antialias below.) still not
	quite right, though.

	crashes with some hipnotic levels.

-- beta 2
	Fixed demo-mode rendering errors.
	Known bugs:
		occassional blue stripes in mipmapped textures
		alias models with incorrect textures; apparently
			a texture caching bug as save/load makes it work
		new particles not showing up
		env var BLASTER not being there in dos causes hang

-- Quake 1.07 beta 1
	Ported to id 1.07 source tree as of 1/22/97. Supports
	Rogue and Hipnotic level packs.
	Known bugs:
	Demos show rendering errors not visible during game play.
       	If no soundblaster in DOS, hangs.


--- Known Problems

	Please send me email (walt@rendition.com) if you have
problems with this release that do not occur with the
version of vquake distributed with your 3D accelerator board.
Please include a system description, and how to duplicate the
problem if at all possible. Thanks.
	
	You must disable UNIVBE if you have it installed. There is no 
reason to run it as the BIOS is VESA VBE 2.0 compliant.

	If Microsoft Networking for DOS is running, the game
may hang when it exits.

	If the game hangs or does not appear to run, reboot,
run vquake with the "-nodma" flag and try again. If it works,
then you probably have an older PCI BIOS and motherboard that
does not work with the Verite chip's busmastering DMA.

	Under Win95, you cannot suspend the game and continue
later. Attempts to do so will crash Win95. For the same reason,
you should turn off any screen savers.

	If a window pops up on the screen (e.g., from a Win95 
background process like a virus scanner), Win95 will crash.

	We have observed improved network performance when we
turn off the screen saver on the Quake server machine.

--- Cvars
	Note: changing these values will affect your performance
	and visual quality.

	d_mipscale (default 1.0)
		increasing it reduces texture detail for 
		more distant objects.

	d_mipcap (default 0)
		increasing it (to 1, 2, or 3) reduces texture
		detail for all objects.

	d_bilerp (default 1)
		setting to 0 turns off texture bilinear filtering.

	d_dither (default 1)
		setting to 0 turns off dithering.

	d_wamp (default 7.0)
		controls amplitude of water warping.

	d_wfreq (default 12.0)
		controls frequency of water warping.

	r_antialias (default 0)
		Use "r_antialias 7" to antialias just about everything,
		including particles.
-----

Related links

• Rendition