Slashdot Mirror


3dfx Voodoo Graphics Gets Windows XP x64 Support

ryszards writes, "GlideXP author Ryan 'Colourless' Nunn has turned his insanity up a notch with a driver that allows running the 32-bit NT Glide .dlls for a Voodoo Graphics board on Windows XP x64. Already supporting Voodoo Graphics and Voodoo 2 on 32-bit Windows XP, adding XP x64 to the mix lets even more folks reminisce about the good old early days of consumer 3D acceleration hardware. Any excuse to fire up GLQuake one more time!"

5 of 104 comments (clear)

  1. Re:Hrm ... by LiquidCoooled · · Score: 3, Informative

    It looks like the low level kernel drivers were just memory mapping and port io.
    The glide interface DLLs (still 32bit) can then communicate correctly with the card using this minimal kernel driver.

    --
    liqbase :: faster than paper
  2. Re:Much better choises than GLQuake available by c0l0 · · Score: 4, Informative

    They did, on a Voodoo 3 or, better yet, Voodoo 5 ;)

    The Voodoo 2 totally lacked 32bit rendering (what was less of a problem back then, given that the other cards' performance numbers were not high enough to render anything at 32bit reliably anyway), and the Voodoo 3 "only" boasted a so-called "22bit post-filter", which provided a MUCH better visual experience at negligible framerate losses. However, (at least european) gaming mags went rabid about the fact that "Voodoo 3 still does not support 32bit color depth!1" (which, again, was nothing to really care about, given other cards' performance at True Color settings!), and until today I'm sure that this kind of hype (and pushing of NVIDIA's TNT2-Chip along with it) did a great deal to sink 3DFX in the end.

    Voodoo 5 supported True Color rendering from the beginning, but the market (or rather the marketing machinery) had moved on to the next hot subject, namely "T&L", by then (which, again, had virtually no real impact on anything that truly mattered for real world games), and due to lack of sales and the high costs 3DFX burdened itself with by acquiring STB, one of the greatest computer graphics companies ever went out of business. Just sad. :(

    --
    :%s/Open Source/Free Software/g

    YTARY!
  3. Re:Speaking of Glide by Atman+Binstock · · Score: 5, Informative

    Has anyone bothered to make a Glide Emulator for some of those games that only supported Glide. There's got to be 1 or 2 Montezuma's Return fans out there :/

    Dunno about that...

    Last time I saw it running on Glide under a recent Windows, there seemed to be a bug where it didn't wait for vsync properly and the CPU got way ahead of the graphics, leading to really ugly control latency. I probably screwed up somewhere :(
    The win32 software renderer didn't have this problem.

    -lead programmer of Montezuma's Return

  4. Security issues by ledow · · Score: 3, Informative

    I think the main focus of the article should really be the poor driver design and the huge security problems.

    Two services, both of which are running as privileged users, which directly map memory and IO space to a user-space process without any significant checks being done on what is asking for access or what it's asking for access to in a common driver running under a networked OS.

    You might say why have a glide card in a server but just how many drivers for other hardware use this same sort of rubbish to interface to their hardware without us knowing? How many still do it under XP, 2003, Vista etc.?

    Every time you install a device driver you are really granting complete machine access to the driver, without audit, without checks. Even in XP x64, he's shown that the ability to create such a driver (one that has privileged access and will grant it to any software that asks for it) requires only a trivial re-compile of a badly-designed driver, using publically available source code, and an install.

    Have people known about this particular driver issue for a long time? Although deliberately introducing malware onto a system via this method would of course require the administrators co-operation, how many third-party device drivers, services, etc. can be subverted to provide that level of access to any software that asks for it?

    That's the scary bit - the fact that the author must be a bit mental to want to run a VooDoo on an XP x64 machine is re-assuring in comparison.

  5. And what's that got to do with anything? by Sycraft-fu · · Score: 3, Informative

    He's right that when the Voodoo 5 came out, multi-chip was not the way to go. It was too expensive and their chips were too slow. A single chip GeForce 2 beat the Voodoos soundly on non-T&L games and annihilated them on ones that did use it. The proof would be in the fact that 3dfx fell from the preeminent 3D company down to something nVidia bought up.

    Also the Voodoo 2 didn't have 3 processors on board, it had 3 chips each which was a part of a single unit. One chip did the frame buffer, the two others were texture units. Together they formed what is a single pipeline on a modern card. While separate chips, you had to have one frame buffer chip and at least one texture chip. Adding more texture chips made multi-texturing faster, but not single texturing. In no case did it help geometry.

    The Voodoo 5 was different. Each VSA was it's own self contained chip. You could use one or you could use more. However they weren't very powerful. It took 2 of them to make a showing at all against things like a GeForce, never mind a GeForce 2. That was not the right way to go. More chips is a valid in visualization systems (which 3dfx chips were oft used in) but not for consumer desktops. As is seen with the SLI market there IS a small market for it for the ubergamers, but it's got to be optional, not mandatory to get reasonable performance.