Just checked Descent and yes, I see the exact same "snow". It's not as bad as in adtrack2 though. Have you seen my video of it? https://app.box.com/s/7wqmsr14m10n0b9my8cv
And I found something else that might have changed either by the recap or BIOS mod. Disabling or enabling write-combining no longer makes any difference in artifacts, while previously it was worse with write-combining enabled.
Can't say that I noticed that jitterring on an LCD, but those lines in your video look the same as in mine. It's not really suprising that it's not as bad for you in that application as I found it to vary depending on program as well. It's by far the worst for me in Descent. The 640x480 switch in the full version pretty much fixes it though, I believe, and I didn't really notice the issues in 1024x768 Windows operation either... I'd guess it's either a flaw of the 2D core itself or some DAC problem specific to low-res modes?
Either way an easy fix is just to have some secondary PCI card for programs where 3dfx cards do this. My Rage II, which is inferior on paper in terms of compatibility, doesn't have any of this at all, as do Nvidia cards I believe.
Not using a Voodoo3 is really not an option for me, as my current goal is to hit top of the charts in Mau1wurf's VGA Benchmark 🤣
But as I said: changing the RAM timings, overclocking the GPU, and enabling triple buffering resolves the issue completely at normal FSB/AGP clocks. Perhaps you could give this a try too, even if only to confirm my findings?
I'll pass for right now, I use a V5 5500 currently and there is no way in hell I'm overclocking this... certainly might give it a shot when I decide to unbrick my V3 3500TV though, and on a 183 MHz card I doubt the overclocking part will be relevant 🤣
I used both 166 and 183 MHz V3s with the stock BIOS and had those issues, so it could be that they had a BIOS version with the "wrong" memory timings per default. The slower memory timings (on 2 of 3 settings, in this case) are usually done for better stability at higher clocks, maybe that could interfere in some way? You should probably also check if triple buffering really does anything, since it doesn't sound like you checked that individually, and in general use it for some time and see if the issues are really gone before drawing a real conclusion 😀
Yeah I don't know if the overclocking and triple buffering really do anything. Only after changing the ram timings I could really see a difference. But perhaps the combination of all these settings did the trick? Besides, enabling triple buffering generally seems like a good idea, can't imagine why it was disabled by default.
I realize it might be a bit too early to draw any conclusions, but since can't see any snow anymore in adtrack (where it was really bad at first) I consider it fixed. Now if only I could fix it at higer AGP clocks, too...
I had a look at the SDRAM chips' datasheet, and the RAM timings recommended in the Voodoo3 programming manual are exactly the minimum required for 6ns chips at 166MHz. My 143MHz model is equipped with 6ns chips too, so these timings should be safe to use.
CAS latency 2 is certainly NOT supported: http://imageshack.com/a/img571/8424/coo0.jpg 🤣
By the way, if anyone was wondering what happened to the high ripple levels I was seeing earlier, this was a measurement error. Most of the noise was actually EMI from my 3Com ethernet switch. After unplugging it, the noise/ripple dropped to acceptable levels.
Before the recap:
+3.3V = 15mVpp
+5.0V = 20-35mVpp
+12.0V = 120mVpp
-12.0V = 15-20mVpp
After recapping, only +5V improved to about 15mVpp. The high noise level on +12V might seem wrong, but not surprising since there are no caps for it anywhere on the mainboard. 120mVpp is still within ATX specs, though.
I just tried all of the different video modes in Descent. The behavior is indeed exclusive to stock 320x200.
The readme hints at 320x240 using "ModeX page flipping to reduce "shearing"", whatever is meant by the latter (and it also hilariously calls the 320x100 mode "a bit" blocky, but that is a different story 🤣). Anyway, on Wikipedia it says this about Mode X:
Higher resolutions: up to 360x480 in 256 colours is possible Double buffering and triple buffering for flicker free animation Sm […]
Higher resolutions: up to 360x480 in 256 colours is possible
Double buffering and triple buffering for flicker free animation
Smooth hardware scrolling of the video display window
Graphics stored in 'off-screen' VRAM can quickly be moved around in VRAM using the VGA latches
Planar mode allows up to 4 adjoining pixels to be modified in one byte write operation, which is ideal for solid filling of objects such as polygons, rectangles, lines, etc.
Screen splitting, where one part of the display is taken from one area of memory and the other from a different area, which is ideal for status displays in games that utilise smooth hardware scrolling
Square pixels are possible where the height/width ratio matches the monitor's, as they usually do in the 320x240 mode.
I'm guessing the 640x400 and 640x480 VESA modes have similar functionality. To me this really hints at some issue with lack of double/triple buffering in plain VGA mode, however the question is why this is not apparent on other cards...
I also really wonder why this is only apparent in Descent. I just tried Dune 2 as a random other game running in 320x200 and there is no "tearing" at all there. Does it use 13h?
I don't know if this has anything to do with Mode X, specifically. And if Voodoo3 lacked double/triple buffering, wouldn't you see horrible screen tearing, instead of snow, on fast machines?
Have you tried Adlib Tracker yet? It runs in 90x30 text mode (that would be 720x480 in pixels) and the "snow" is more visible there than in any VGA game. Also notice how it gets better while playing a track, or bringing up any menu window.
No, I haven't tried that yet. I'll do so. I'm just looking into those different modes because it is rather mysterious to me how the issue is only present in certain games, and totally absent in others...
Adlib Tracker II, right?
I don't get the issues here on the Voodoo5, just a tad of noise on the edges of lines etc. which I've had on other stuff too on this LCD/VGA combination... the video mode is detected as 640x480/60 Hz by the monitor instead of 720x480 though.
Not entirely related to the topic perhaps, but since you are using a CRT, can you try PCPBENCH on your computer? On this LCD I was getting weird discharge patterns on this Pentium III/Voodoo5 machine, but on my Pentium 200 MMX with Rage II card everything was fine.
wrote:Adlib Tracker II, right?
I don't get the issues here on the Voodoo5, just a tad of noise on the edges of lines etc. which I've had on other stuff too on this LCD/VGA combination... the video mode is detected as 640x480/60 Hz by the monitor instead of 720x480 though.
Weird... what happens when you overclock the AGP bus a bit?
640x480 is definitely wrong, or else all characters would be 7.11 pixels wide. I think your monitor just counts the 480 lines and assumes it's 640px horizontal.
wrote:Not entirely related to the topic perhaps, but since you are using a CRT, can you try PCPBENCH on your computer? On this LCD I was getting weird discharge patterns on this Pentium III/Voodoo5 machine, but on my Pentium 200 MMX with Rage II card everything was fine.
When not overclocked I don't see anything wrong in PCPBench (VGA mode 13h). But on even a slight OC, for example 115MHz with 2/3 divider, the screen appears to jump up and down occasionally.
With this Voodoo5 usually the PC won't even boot with a slight FSB OC. The card is quite sensitive to that.
From past experiences with FSB overclocking on Voodoo3 I can tell you that the tearing became even worse in Descent. I've also had IDE corruption from having the FSB at 133 MHz at one point.
