sliderider wrote:

The 8mb of onboard RAM on an AGP i740 is only for 2D framebuffer.

All frame buffers can be stored in local memory.

My Savage IX 8MB has good compatibility but similar performance. I am convinced those mobile chips have 32 bit memory bus.

I recently got a Riva128ZX and tried it with Dethkarz. With the 4 MB Riva128 I noticed in Dethkarz short texture loading breaks, when I collected a bonus cube. With the 8 MB ZX Dethkarz runs pretty well, often capped at 30 fps, sometimes it drops to 20 fps.

For my own study i've screenshotted a Quake2 scene on a Voodoo2 then on a Rage, then in software mode. Kinda fun to layer them over each other in a program and fading in and out to see the (already well known) visual differences. The Voodoo2 screenshot represents the common way Quake2 was seen throughout 1998, what with the high gamma and the blur. I loaded MesaFX on to take a screenshot without the filtering.

EDIT: Replaced screenshots with more consistent ones, and gamma corrected the Rage Pro screenshot

This is all with the ICD I suppose? Since AFAIK the final 3dfx OpenGL ICD was only released in 99 I would assume that people would have used the MiniGL with the V2 in 98 (just because it says 3dfx...), which can lead to lower quality textures and resolution limitations with some games.

The unfiltered screenshot was done on the ICD, the filtered one was done with the MiniGL that ships with Quake2 (3dfxgl.dll)

Voodoo2 wins for me, I don't like green corners but still better then going black like Rage Pro.

Added a Geforce FX screenshot.

I just realized something - 3dfxgl.dll apparently postprocesses the screenshot?!

leileilol wrote:

I just realized something - 3dfxgl.dll apparently postprocesses the screenshot?!

That's why still frames in magazine reviews always look horrible when comparing 3dfx cards to other makers cards. With other makers cards, the screenshots are more or less complete and representative of what you see on the monitor. With 3dfx cards, there's still some work left to be done before the image gets sent to the screen so screenshots with 3dfx cards don't display the finished image.

It's obvious with using a Glide wrapper.

The Quake2 screenshot function is nothing more than a bunch of glReadPixels saved to a 24-bit TGA. 3dfxgl.dll is applying that filter in software

(would be nice to have this filter in real time, but..... 😀)

On another board I thought it would be a funny idea to try to run the latest Doom source ports on the Voodoo2. I only had success with Prboom+ and Zandronum so far, most ports rely on recent Microsoft libraries and regress older platforms 🙁

Huh, OpenGL in Zand only gave me garbage on that kind of hardware. I presume you certainly weren't using stock drivers for this 😀

Hi at all ,in this topic missing the Creative 3Dblaster with Glint processor and VESA bus !

Finally browsing through this thread again, or at least the most recent additions before it went idle, but that Quake 2 comparison above is really interesting:
Retro 3D Accelerator Screenshot Collection

I haven't seen the Rage Pro dither like that before, or maybe it's just a weird circumstance in that particular scene, but it looks much more diffused and less ordered than most Rage stuff (or most 16-bit render dither patterns in general). There's some very ordered dithering looking bits (like the gun and water), but the rest is very diffused.

The Geforce just seems to use a much lower threshold and thus end up with mostly checkerboard dither at the expense of more posterization (like maybe truncating to 6-6-6 RGB before dithering to 5-5-5 or 5-6-5 output). Wish earlier cards had done that, it seems like a simple thing to do yet most seemed to try to approximate 24-bit color depth with lots more dither. (I always liked the low threshold dithered shading Tie Fighters DOS engine used, shame that wasn't more popular -in software renderers for that matter, given most opted for hard thresholding rather than any dither at all, even though pretty simple LUTs could generate 2-color alternating pixel outputs rather than single values for shading or blending -quake/doom style lighting could use it pretty easily)

I tried to recreate the Nvidia dithering in a shader but couldn't get enough room for a big enough dither table that compiled. I think it's a 16x16 "Restore Down" pattern 🙁

On second look, I also think the software filter the 3dfxgl.dll capture is applying isn't as nice as the actual Voodoo 3's filter, it seems blurrier like single or maybe double-pass horizontal (scanline) filter effects some console emulators use to fake composite video blur. The real deal is NOT that blurry and merely softens the dither (blends it more at high res, but at 640x480 the pixels are quite apparent) and is pretty nice on the whole, all things considered. (320x240 is grainy ... not that you'd ever need to run that low, but for comparison purposes the filter is mostly useless -slight softening, no real blending, but I suppose nicer on the eye than full unfiltered output; the bigger deal is the dither patterns on the Voodoo are easily demonstrated to be nicer than Riva 128 or Rage Pro -or Rage II- )

Given the Voodoo2/3 GPU seems to do all the necessary computation for 24-bit framebuffer output (just dithers the 24-bit pixel results to 16-bit for the output) it's a bit of a shame they didn't include a 24 or 32-bit color option. (limited max res and fillrate compared to 16-bit, but that's true for plenty of cards with 24/32-bit options or all cards as far as resolution goes -would be nice for SLI given each board only renders half the screen anyway, texture RAM ends up fully redundant, but framebuffer RAM doesn't)

Plus the lack of dither makes running at lower res less of a problem. (and the Voodoo's filter still acts as a modes pixel-edge AA effect) Color banding (and dither) are fairly noticeable in Unreal's fog effects where they aren't in the Software Renderer's 32-bit option (or even Rage Pro's 32-bit) though the Voodoo 2/3 obviously has other quality and performance advantages.

A bit off topic, but is it normal for Voodoo 3's to run really, really hot? (like passive heatsink /and/ back side of the card PCB burns to the touch) In this case a Voodoo 3 2000. It makes me nervous running in my P5A-B with it's limited PCI slots, butted up against the sound card or USB card I have installed. (an AGP Voodoo 3 would be in a nicer location, but ... ) I could always dig our the old Voodoo2 and run it in tandem with my AGP Rage Pro I suppose. (only have the 1, otherwise I'd consider going SLI -plus side of that P5A-B in spite of having only 3 PCI slots and being baby AT, none are blocked by the CPU)

Yes, perfectly normal 😀
I had my first hardware-burn from the silver heatsink of a Voodoo 3 3000 AGP 😁

kool kitty89 wrote:

On second look, I also think the software filter the 3dfxgl.dll capture is applying isn't as nice as the actual Voodoo 3's filter

i really hope you're not confusing the 4x1 filter (which 3dfxgl.dll imitates) with the 2x2 "22-bit" filter the Voodoo3 will also use (and sometimes default to). That one doesn't have the characteristic 'lines' but is also more muddy for lower resolutions and is more aggressive towards edges.

P200MMX / 64MB EDO-RAM / SiS 5598 / Rendition V2200 4MB / Videologic Apocalypse 3D (PCX1)
Monster Truck Madness 640x480(max)

Lensflares seem to be a problem.

Judging by the dither it's rendition right