mirror of
https://github.com/dege-diosg/dgVoodoo2
synced 2024-07-08 20:51:02 +02:00
442 lines
18 KiB
HTML
442 lines
18 KiB
HTML
|
<!DOCTYPE html>
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<style>
|
||
|
|
|
||
|
|
p
|
||
|
|
{
|
||
|
|
max-width:1000px;
|
||
|
|
word-wrap:break-word;
|
||
|
|
text-align: justify;
|
||
|
|
}
|
||
|
|
|
||
|
|
li {
|
||
|
|
max-width:1000px;
|
||
|
|
text-align:justify
|
||
|
|
}
|
||
|
|
|
||
|
|
table, th, td {
|
||
|
|
width:1000px;
|
||
|
|
border: 1px solid #C0C0C0;
|
||
|
|
border-collapse: collapse;
|
||
|
|
text-align: center;
|
||
|
|
}
|
||
|
|
|
||
|
|
a:link {
|
||
|
|
color: green;
|
||
|
|
background-color: transparent;
|
||
|
|
text-decoration: none;
|
||
|
|
}
|
||
|
|
|
||
|
|
a:visited {
|
||
|
|
color: pink;
|
||
|
|
background-color: transparent;
|
||
|
|
text-decoration: none;
|
||
|
|
}
|
||
|
|
|
||
|
|
a:hover {
|
||
|
|
color: red;
|
||
|
|
background-color: transparent;
|
||
|
|
text-decoration: underline;
|
||
|
|
}
|
||
|
|
|
||
|
|
a:active {
|
||
|
|
color: yellow;
|
||
|
|
background-color: transparent;
|
||
|
|
text-decoration: underline;
|
||
|
|
}
|
||
|
|
|
||
|
|
</style>
|
||
|
|
|
||
|
|
<head>
|
||
|
|
|
||
|
|
<meta name="google-site-verification" content="4JMbYsGNl4-uZV9FEQvq56CQDND5NHcIPtMblynaH-Q" />
|
||
|
|
|
||
|
|
<title>dgVoodoo2 Glide Readme</title>
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body bgcolor="#552F00">
|
||
|
|
<font color = "#A0A060">
|
||
|
|
|
||
|
|
<h2 align="left">
|
||
|
|
===============================================================================<br>
|
||
|
|
<font color = "#FFFFFF">dgVoodoo 2.7</font>: Glide related stuffs<br>
|
||
|
|
<br>
|
||
|
|
===============================================================================<br>
|
||
|
|
</h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
<h2><font color = "#FFFFFF"><u>
|
||
|
|
Table of contents
|
||
|
|
</u></font></h2>
|
||
|
|
<b><h3>
|
||
|
|
1. Glide options<br>
|
||
|
|
2. Glide additional options<br>
|
||
|
|
3. Gamma correction<br>
|
||
|
|
4. Some technical info<br>
|
||
|
|
5. Napalm build<br>
|
||
|
|
6. Tips and known issues<br>
|
||
|
|
</h3></b>
|
||
|
|
</p>
|
||
|
|
===============================================================================<br>
|
||
|
|
|
||
|
|
<h2><font color = "#FFFFFF"><u>
|
||
|
|
1. Glide options
|
||
|
|
</u></font></h2>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><font color = "#FFFFFF"><b>3Dfx card</b></font>
|
||
|
|
<p>
|
||
|
|
Selected card type affects the following:
|
||
|
|
<ul>
|
||
|
|
<li>Limits your choice possibilities in respect of 'Onboard RAM',
|
||
|
|
'Texture memory' and 'Number of TMUs' according to the
|
||
|
|
card type. Some applications (like the miniGL driver)
|
||
|
|
may check for those values and won't work if one of them
|
||
|
|
is too high. So it is more handy to select a card type
|
||
|
|
to limit those values alltogether than configuring
|
||
|
|
one-by-one by heart.</li>
|
||
|
|
<li>Some exposed capabilites. See techical info for more.
|
||
|
|
List of different card caps/behaviors may be extended in the future,
|
||
|
|
according to 3dfx specs.</li>
|
||
|
|
</ul>
|
||
|
|
</li></p>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Onboard RAM</b></font>
|
||
|
|
<p>
|
||
|
|
Videomemory without texture memory. Some application
|
||
|
|
compute by this value that what resolutions are supported.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li><font color = "#FFFFFF"><b>Resolution/MSAA</b></font>
|
||
|
|
<p>
|
||
|
|
You can force the resolution, the refresh rate and MSAA.<br>
|
||
|
|
If the refresh rate is unforced (or enumerating refresh rates is disabled) then the application selected one will be used.
|
||
|
|
If the application defines a default refresh rate then 60Hz is used instead.
|
||
|
|
<br>
|
||
|
|
If the chosen refresh rate is unsupported by your monitor at a given resolution then the closest supported one will be selected.
|
||
|
|
<br><br>
|
||
|
|
Option 'Application driven' for MSAA has meaning only for
|
||
|
|
Napalm build. For non-Napalm builds it is equivalent to 'Off'.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Number of TMUs</b></font>
|
||
|
|
<p>
|
||
|
|
This version can emulate more than one Texture
|
||
|
|
Management Units.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Texture mem size</b></font>
|
||
|
|
<p>
|
||
|
|
Onboard RAM and texture memory are unified video memory on
|
||
|
|
UMA 3Dfx cards (see table in technical info). Future
|
||
|
|
versions of the CPL app may not allow to config them
|
||
|
|
separately.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Filtering</b></font>
|
||
|
|
<p>
|
||
|
|
You can force the texture filtering to either point sampled or bilinear; or simply leave it at application default.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Disable mipmapping</b></font>
|
||
|
|
<p>
|
||
|
|
I liked it in some games that looked nicer without mipmapping. :)
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Enable Glide-gamma ramp</b></font>
|
||
|
|
<p>
|
||
|
|
See section "Gamma Correction".
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Force VSync</b></font>
|
||
|
|
<p>
|
||
|
|
Forces at least one vertical retrace before buffer swapping. Use this option if something gets too fast.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Force Emulating True PCI Access</b></font>
|
||
|
|
<p>
|
||
|
|
see section 'Some techincal info'
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>16 bit depth buffer</b></font>
|
||
|
|
<p>
|
||
|
|
see section 'Tips'
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>3Dfx Watermark</b></font>
|
||
|
|
<p>
|
||
|
|
Enables displaying the 3Dfx logo during the app animation.
|
||
|
|
You need the 3Dfx splash dlls for this. If they are
|
||
|
|
missing, no logo will be displayed.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>3Dfx Splash screen</b></font>
|
||
|
|
<p>
|
||
|
|
Enables splash screen at game/app startup.
|
||
|
|
You need the 3Dfx splash dlls for this. If they are
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
|
||
|
|
<li><font color = "#FFFFFF"><b>Pointcast Palette Driver Build</b></font>
|
||
|
|
<p>
|
||
|
|
see section 'Some techincal info'
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li><font color = "#FFFFFF"><b>Enable inactive app state</b></font>
|
||
|
|
<p>
|
||
|
|
Glide games/demos can have two bad habits:
|
||
|
|
<ul>
|
||
|
|
<li>Cannot tolerate losing application focus (Alt-Tabbing to another application) and crash or quit.</li>
|
||
|
|
<li>Do not pump the message queue of their window - it was not a problem on Win95/98 but today's Windows' treat the state of such applications 'Not responding'.</li>
|
||
|
|
</ul><br>
|
||
|
|
By default, dgVoodoo tries to avoid, and to workaround those cases with some extra work.<br>
|
||
|
|
However it can unfortunately cause other unexpected issues in some games; if it does then you can enable this option instructing dgVoodoo not to intervent.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<h2><font color="#FFFFFF"><u>
|
||
|
|
2. Glide additional options
|
||
|
|
</u></font></h2>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><font color = "#FFFFFF"><b>Dithering</b></font>
|
||
|
|
<p><ul>
|
||
|
|
<li><b>Disabled</b>: Dithering is always disabled, ending up 16-bit quality rendering</li>
|
||
|
|
<li><b>Appdriven</b>: The application can choose between disabling, dithering2x2 and dithering4x4</li>
|
||
|
|
<li><b>ForceAlways</b>: Dithering is always enabled and the selected dithering effect is applied <font color="#FFFFFF">(default)</font></li>
|
||
|
|
</ul></p></li>
|
||
|
|
<li><font color = "#FFFFFF"><b>DitheringEffect</b></font>
|
||
|
|
<p><ul>
|
||
|
|
<li><b>Dither2x2</b>: Ordered dithering with a 2x2 dithering matrix</li>
|
||
|
|
<li><b>Dither4x4</b>: Ordered dithering with a 4x4 dithering matrix</li>
|
||
|
|
<li><b>Pure32Bit</b>: 32 bit rendering quality <font color="#FFFFFF">(default)</font></li>
|
||
|
|
</ul></p></li>
|
||
|
|
<li><font color = "#FFFFFF"><b>DitherOrderedMatrixSizeScale</b></font> - integer scale value for dither matrix size
|
||
|
|
<p><ul>
|
||
|
|
<li>1 = normal, 2 = double size, etc.</li>
|
||
|
|
<li>0 = automatic (the aim is to have some retro feel&look) <font color="#FFFFFF">(default)</font></li>
|
||
|
|
</ul></p></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<h2><font color = "#FFFFFF"><u>
|
||
|
|
3. Gamma correction
|
||
|
|
</u></font></h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
A gamma correction curve can be set through the Glide interface. Since Glide
|
||
|
|
uses a linear curve by default it might not match the default or one's taste
|
||
|
|
and can look ugly (at least in the old days, I remember it looked ugly on CRTs).
|
||
|
|
For the standard see sRGB on google.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
That's why the CPL has the 'Enable Glide gammaramp' option: you can disable
|
||
|
|
the curve coming from Glide and let your monitor use the default.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
*As taking a closer look into this, I realized that a linear curve is used by
|
||
|
|
the nowadays adapters by default but they probably post-calibrate it according
|
||
|
|
to the sRGB standard. So Glide's linear curve won't change anything to wrong.
|
||
|
|
I'm little confused about this. Back in the old days my real problem could be
|
||
|
|
that either brightness of my CRT was too high by default or sRGB was not
|
||
|
|
followed by the adapters therefore some gamma-adjusting game had really bad (pale
|
||
|
|
and really bright) look. I do not know it by now but won't remove the possibility
|
||
|
|
of disabling Glide gamma ramp. Test it on your monitor.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Color adjustments are supported in both fullscreen and windowed mode however
|
||
|
|
brightness is always calculated into the gamma ramp curve in fullscreen so
|
||
|
|
it has effect only if your adapter supports setting up gamma curves.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<h2><font color = "#FFFFFF"><u>
|
||
|
|
4. Some technical info
|
||
|
|
</u></font></h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Unfortunately Glide cannot be implemented in practice as a standalone API which
|
||
|
|
is completely independent on the underlying hardware. If someone looks through
|
||
|
|
the Glide SDK then it is clear that this API is suited for the 3Dfx Voodoo
|
||
|
|
hardware and its registers. However there are rules even in Glide (as in other
|
||
|
|
APIs too) that must be observed in respect of driving the API. An application
|
||
|
|
should never assume anything about the hardware being driven even if it knows
|
||
|
|
what hardware it is driving. The application should get all the info from the
|
||
|
|
API and keep the driving rules.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
However in practice there are some application violating those rules very hard.
|
||
|
|
Since Glide provides free direct access to the frame buffer it is typical to
|
||
|
|
utilize the properties of a real 3Dfx hardware connected to the PCI bus. For
|
||
|
|
example, writing to the frame buffer while it was requested to lock for reading,
|
||
|
|
swapping buffers while one/some of the buffers are locked and assuming that the
|
||
|
|
mapped pointers of buffers remains unchanged, using 2048 bytes as frame buffer
|
||
|
|
stride, or drawing simultaneously by the 3D hardware and LFB writes through the
|
||
|
|
PCI bus even when a buffer was locked with idle 3D hardware mode.
|
||
|
|
Most of them can be workarounded easily but there is one case which can cause
|
||
|
|
performance drop if emulated perfectly. This case is the mentioned simultaneous
|
||
|
|
writing. dgVoodoo can emulate this usecase but you must enable it explicitly so
|
||
|
|
I reluctantly inserted an option into the CPL, named
|
||
|
|
'Force emulating true PCI access'. This is the only technical option related to
|
||
|
|
the quality of the implementation. There are only a few games it should be used
|
||
|
|
for (see 'Tips') so it would be a pity to have it pointlessly enabled for the
|
||
|
|
rest.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
There is another strange option in the CPL, namely 'Pointcast Palette driver
|
||
|
|
build'. Well, early 3Dfx hardware allowed separate texture palettes/ncc tables
|
||
|
|
for each TMU so this possibility was reflected in Glide 2.11 and 2.43. However,
|
||
|
|
latter 3Dfx hardware used a unified memory model meaning that only one global
|
||
|
|
palette/ncc could be set for all the TMUs. Glide3 don't even allow to set them
|
||
|
|
in any other way. The funny thing is that original Glide2 drivers internally
|
||
|
|
also forced the global palette/ncc thing despite the API allowed separate ones.
|
||
|
|
It was because of pushing the programmers towards the future hardware. But, maybe
|
||
|
|
there were drivers built for custom vendors with the capability of separate
|
||
|
|
tables. So if this option is enabled in the CPL then such a driver build is
|
||
|
|
emulated but it has effect only on non-UMA cards. I don't think that any Glide
|
||
|
|
application in the world requests such a driver build so always keep this option
|
||
|
|
disabled. It just makes the appearance wrong if more than one TMU are used.
|
||
|
|
This option is only for the sake of fullness.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
dgVoodoo exposes the following Glide capabilities according to the selected card
|
||
|
|
type:
|
||
|
|
</p>
|
||
|
|
<table bgcolor = "#653F00">
|
||
|
|
<tr><th><font color = "#FFFFFF">Card type</font></th><th><font color = "#FFFFFF">FBI revision</font></th><th><font color = "#FFFFFF">TMU revision</font></th><th><font color = "#FFFFFF">Glide3 extensions</font</th><th><font color = "#FFFFFF">UMA</font></th></tr>
|
||
|
|
</font>
|
||
|
|
|
||
|
|
<tr><td><font color = "#FFFFFF">? (unexposable via dgVoodoo)</font></td><td>0x0001</td><td>0x0000</td><td>-</td><td>no</td></tr>
|
||
|
|
<tr><td><font color = "#FFFFFF">Voodoo Graphics (SST-1)</font></td><td>0x0002</td><td>0x0001</td><td>GETGAMMA</td><td>no</td></tr>
|
||
|
|
<tr><td><font color = "#FFFFFF">Voodoo Rush (SST-96)</font></td><td>0x0002</td><td>0x0001</td><td>GETGAMMA, CHROMARANGE</td><td>no</td></tr>
|
||
|
|
<tr><td><font color = "#FFFFFF">Voodoo 2</font></td><td>0x0002</td><td>0x0001</td><td>GETGAMMA, CHROMARANGE, TEXMIRROR, PALETTE6666</td><td>no</td></tr>
|
||
|
|
<tr><td><font color = "#FFFFFF">Voodoo Banshee</font></td><td>0x1002</td><td>0x1001</td><td>GETGAMMA, CHROMARANGE, TEXMIRROR, PALETTE6666, TEXUMA, TEXTUREBUFFER</td><td>yes</td></tr>
|
||
|
|
<tr><td><font color = "#FFFFFF">Other (greater)</font></td><td>0x100003</td><td>0x100002</td><td>GETGAMMA, CHROMARANGE, TEXMIRROR, PALETTE6666, TEXUMA, TEXTUREBUFFER, FOGCOORD, TEXCHROMA, *PIXEXT, *COMBINE, *TEXFMT, *SURFACE, *GETREGISTRY</td><td>yes</td></tr>
|
||
|
|
</table>
|
||
|
|
|
||
|
|
* Available in Napalm build only
|
||
|
|
|
||
|
|
<br>
|
||
|
|
<br>
|
||
|
|
<h2><font color = "#FFFFFF"><u>
|
||
|
|
5. Napalm build
|
||
|
|
</u></font></h2>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Why is a separate build needed for Napalm? Why not just use it as a plain Glide3
|
||
|
|
implementation in general? Well, the answer is about the performance, again.
|
||
|
|
Napalm has a bit more complicated shaders in order to handle Voodoo4 features
|
||
|
|
like extended combine modes, 32 bit rendering, 32 bit texture formats and big
|
||
|
|
textures. So, it would be wasting of GPU resources to use it with Glide3
|
||
|
|
applications not requiring these features (that is, all apps except <font color = "#FFFFFF">Project64</font>, in
|
||
|
|
practice :) ).
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Note that there is no significant difference between Glide3 and Glide3 Napalm
|
||
|
|
as for performance if dynamic shader compiling is enabled. In both cases, much
|
||
|
|
more optimal shaders are compiled and used than the precompiled ones.
|
||
|
|
<br>
|
||
|
|
Some limitiations:
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><p>Compressed textures (FXT1, DXT*) are not supported. :(</p></li>
|
||
|
|
<li><p>Reading/writing stencil values via 32 bit aux lfb lock won't work.</p></li>
|
||
|
|
<li><p>T-Buffer writemask can only be controlled by the application if antialiasing
|
||
|
|
mode is set to 'App driven'.</p></li>
|
||
|
|
<li><p></to>SURFACE and GETREGISTRY extension are only used by the 3Dfx OpenGL 1.1 driver
|
||
|
|
which is an OpenGL -> (Glide3 Napalm and DirectDraw) wrapper. Since Glide3
|
||
|
|
operates on surfaces created by DirectDraw (3Dfx implementation), SURFACE
|
||
|
|
functionality cannot be implemented. It means that original 3Dfx OpenGL driver
|
||
|
|
won't work with a standalone Glide3 wrapper (it would make no sense but would
|
||
|
|
be nice).
|
||
|
|
Since OpenGL does not work, GETREGISTRY functionality is also needless. So,
|
||
|
|
those two extensions are only placeholders, bunch of empty functions.</p></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Don't forget to set card type to 'Other (greater)' with 2 TMUs in the CPL to
|
||
|
|
emulate a Voodoo4.
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<br>
|
||
|
|
|
||
|
|
<h2><font color = "#FFFFFF"><u>
|
||
|
|
6. Tips and known issues
|
||
|
|
</u></font></h2>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><p>Forced trilinear texture filtering is not available in this wrapper version
|
||
|
|
but an application can implement it by 2 drawing passes if one TMU is used.
|
||
|
|
If more than one TMU are enabled then it can be done by one pass. Since
|
||
|
|
more TMUs are generally used for drawing the same as with one TMU but with
|
||
|
|
less passes, enabling multiple TMUs can be useful even if the gpu is loaded
|
||
|
|
with heavier shader code. It depends. Try out both cases.
|
||
|
|
</p></li>
|
||
|
|
<li><p>Keep in mind that not all Glide application are usable in windowed mode. Some
|
||
|
|
of them behave very well while others may not at all. Since they were
|
||
|
|
designed for an environment with one monitor and exclusive fullscreen display,
|
||
|
|
an application can get minimized or simply quits when its window loses the
|
||
|
|
focus. Also, they may capture the mouse into a fix area and you cannot even
|
||
|
|
move the game window. Or worse: if this fix area is hardcoded and (so) is on
|
||
|
|
the primary monitor then you can play the game only on the primary monitor even
|
||
|
|
in fullscreen mode. dgVoodoo tries to workaround these cases by hiding some
|
||
|
|
events from the application but generally it is not enough.
|
||
|
|
</p></li>
|
||
|
|
<li><p>DosBox: dgVoodoo works perfectly with Gulikoza's
|
||
|
|
newest Glide patch. Keep in mind that Extreme Assault needs a 3Dfx card with
|
||
|
|
non-UMA architecture (see table of exposed caps) and PCI emulation.
|
||
|
|
</p></li>
|
||
|
|
<li><p>Emulating PCI access is optimized for applications locking and accessing the
|
||
|
|
LFB very frequently (per frame). Altough it provides faster lfb data access than
|
||
|
|
doing the normal way, I cannot recommend to use it in general for all apps.
|
||
|
|
Due to nature of the technique used it can cause slowdown in applications
|
||
|
|
that access the lfb "regularly", that is, once or twice per frame.
|
||
|
|
Carmageddon 1, Extreme Assault, Dreams To Reality and Pyl are the only cases
|
||
|
|
where it has to be used, afaik.
|
||
|
|
</p></li>
|
||
|
|
<li><p>A strange case: when I tried to run a Glide based scene-demo, TBC,
|
||
|
|
it always crashed at a certain point due to stack overflow. I had to
|
||
|
|
manually grow the reserved stack size of the exe file to get it to run.
|
||
|
|
Probably a real 3Dfx driver required smaller stack than a Direct3D11
|
||
|
|
based driver.<br>
|
||
|
|
<a href="(http://xona.com/tobecontinued/)">(http://xona.com/tobecontinued/)</a>
|
||
|
|
</p></li>
|
||
|
|
<li><p>I ran into a problem with NFS 3 Hot Pursuit: ugly z-fighting which is most
|
||
|
|
noticable with projected headlights. This game does not use depth bias
|
||
|
|
but utilize the inaccuracy of the 16 bit voodoo depth buffer when rendering
|
||
|
|
polygons onto each other (I'm not sure if it was intentional or just a bug).
|
||
|
|
If an app uses z-buffering then using a 16 bit depth buffer in the emulation
|
||
|
|
provides the correct and exact mapping of the z values, like on a real Voodoo.
|
||
|
|
And so NFS3 HP also works well with a 16 bit depth buffer. I was thinking on
|
||
|
|
how to workaround this problem or automate this mechanism but found no way.
|
||
|
|
So, reluctantly again, I exposed this into an option in the CPL...
|
||
|
|
This is the second option related to the quality of the implementation,
|
||
|
|
aaaarrghh.
|
||
|
|
</p></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
<font>
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|