ReactOS now supports 3dfx's Voodoo5 GPUs — open-source Windows alternative offers near-native performance for retro gamers
Useful if you still have a Voodoo card buried in your closet.

ReactOS, the free open-source operating system that aims to achieve binary compatibility with Windows NT, now has a working video driver for 3dfx's iconic Voodoo5 GPUs, via Phoronix. The developers are reporting near-native performance in OpenGL applications using MesaFX and WickedGL ICDs (Installable Client Drivers), with a few caveats.
Back in the late 90s, 3dfx Interactive was a major force in the GPU market, reknowned for its Voodoo lineup of graphics accelerators that ended with the Voodoo5. Now only a source for nostalgia, the Voodoo5 GPUs are a prized item among retro gamers and collectors, largely due to their iconic status and compatibility with games made using the Glide API. The Voodoo5 family was the fastest and last lineup of GPUs by 3dfx, with five variants envisioned, yet only the Voodoo5 5500 AGP and PCI variants made it to consumers.
Through experimental patches, a contributor project has gotten Voodoo5 drivers up and running on ReactOS. In theory, this compatibility should extend to the Voodoo4 family as well, which utilizes the same VSA-100 GPU core. Testing indicates that Epic Games’ Unreal (1998) launches and runs smoothly in full-screen modes with the new driver.
Update: simonelombardo reports you can reach full speed in OpenGL when you install MesaFX/WickedGL, if you use Voodoo 4/5 drivers with #ReactOS.These ICDs do not support windowed mode, though. https://t.co/5Klvz07V9k pic.twitter.com/opAktL3zA9April 19, 2025
The developers followed up by reporting ‘full speed’ OpenGL performance with MesaFX and WickedGL, both of which are third-party ICDs tailored for 3dfx hardware. ICDs translate OpenGL API calls directly into instructions the old 3dfx GPUs can understand. Full-speed in this context likely refers to performance comparable to the original Windows environment with the same card and ICDs. The caveat is that windowed mode is not supported, but that quirk should be ironed out with a few patches.
ReactOS is not production-ready, as it's still in its Alpha stage and has been under development since 1996. The latest numbered release, version 0.4.15, came out last month and brings plug-and-play support, better memory management, more audio formats, and several bundled accessories, just to name a few. As it stands, ReactOS serves primarily for testing and validation. However, with increased compatibility, it could offer a more secure environment for legacy hardware and retro gamers compared to outdated Windows NT releases.
Follow Tom's Hardware on Google News to get our up-to-date news, analysis, and reviews in your feeds. Make sure to click the Follow button.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.

Hassam Nasir is a die-hard hardware enthusiast with years of experience as a tech editor and writer, focusing on detailed CPU comparisons and general hardware news. When he’s not working, you’ll find him bending tubes for his ever-evolving custom water-loop gaming rig or benchmarking the latest CPUs and GPUs just for fun.
-
das_stig ReactOS need to stop and rethink their path, they should be targeting Windows 10 compatibility. At current progress, it will just be a plaything and pipedream rather than an alternative.Reply -
Mark Knight The voodoo 5 cards were NOT iconic, they were a failure and put 3dfx out of business.Reply -
USAFRet 'near native' performance.Reply
So, almost but not quite being able to match performance of 25 year old hardware. -
_deXter_ das_stig said:ReactOS need to stop and rethink their path, they should be targeting Windows 10 compatibility. At current progress, it will just be a plaything and pipedream rather than an alternative.
Maybe you need to stop and rethink what ReactOS is all about (hint: it was never about being an alternative for recent Windows versions). Besides, you need to be able to walk before you can run—and that's what they're focusing on right now, so targeting XP/2003 era APIs is a very practical goal. Also, most of the underlying APIs from that era are unchanged and still in use today in Win10/11, so it's not like they're wasting time here.
Also, ReactOS is not a "plaything", it has actual real-world use cases such as in embedded and industrial applications, where you're running expensive/specialised hardware and you don't have the option to upgrade to a recent supported OS. At my previous workplace for instance, we had a bunch of very, very expensive scientific instruments that ran Windows XP Embedded, each of which had a custom PCI card (not PCIe, mind you) to interface with the core instruments. We had a requirement to securely sync that data to the production network, but naturally you can't connect such an old OS to a modern network. Security issues aside, the protocols used in that era (like SMBv1) were super flaky (we used an intermediary server to sync the data, but the system was pretty unreliable overall). So as an experiment, we installed ReactOS on one of the machines (which was my idea btw), and surprisingly, it all just worked - even the instrument control drivers and software ran without a hitch. This allowed us to switch to the NFS protocol, which made the sync process so much more reliable that all our previous issues was now a thing of the past. I moved on from that role shortly afterwards so I'm not sure if they ever upgraded the rest of the machines in prod, but the point is that it showed that ReactOS was a legit alternative for people running ancient hardware. -
das_stig
It's great and a sign they are heading in the right direction, that the OOBE all worked for you and yes I know all about it goals and why XP era etc and have read the blurb, still stand by my comment that Win10 should be its target and a true alternative. Yet if they want to be taken seriously, they must fix their website, so many broken bits or content inaccessible and of course the $1m question, when will it be v1.0 production ready, another 20 years when it will be irrelevant?_deXter_ said:Maybe you need to stop and rethink what ReactOS is all about (hint: it was never about being an alternative for recent Windows versions). Besides, you need to be able to walk before you can run—and that's what they're focusing on right now, so targeting XP/2003 era APIs is a very practical goal. Also, most of the underlying APIs from that era are unchanged and still in use today in Win10/11, so it's not like they're wasting time here.
Also, ReactOS is not a "plaything", it has actual real-world use cases such as in embedded and industrial applications, where you're running expensive/specialised hardware and you don't have the option to upgrade to a recent supported OS. At my previous workplace for instance, we had a bunch of very, very expensive scientific instruments that ran Windows XP Embedded, each of which had a custom PCI card (not PCIe, mind you) to interface with the core instruments. We had a requirement to securely sync that data to the production network, but naturally you can't connect such an old OS to a modern network. Security issues aside, the protocols used in that era (like SMBv1) were super flaky (we used an intermediary server to sync the data, but the system was pretty unreliable overall). So as an experiment, we installed ReactOS on one of the machines (which was my idea btw), and surprisingly, it all just worked - even the instrument control drivers and software ran without a hitch. This allowed us to switch to the NFS protocol, which made the sync process so much more reliable that all our previous issues was now a thing of the past. I moved on from that role shortly afterwards so I'm not sure if they ever upgraded the rest of the machines in prod, but the point is that it showed that ReactOS was a legit alternative for people running ancient hardware. -
mitch074
Actually, since ReactOS uses Wine for API support the only reason they'd switch to Win10 as a target would be to isolate the graphics drivers from kernel space - as that's the main difference between the Windows Server 2003 kernel they're clean-room reverse engineering and the Vista/7/8/10 kernel. Maybe the scheduler...? But then they can swap a scheduler out and implement their own based on Linux ones as well.das_stig said:It's great and a sign they are heading in the right direction, that the OOBE all worked for you and yes I know all about it goals and why XP era etc and have read the blurb, still stand by my comment that Win10 should be its target and a true alternative. Yet if they want to be taken seriously, they must fix their website, so many broken bits or content inaccessible and of course the $1m question, when will it be v1.0 production ready, another 20 years when it will be irrelevant?
I'm not so sure anybody would really be interested in all the entry points for spyware that Microsoft added later on, so... -
snemarch
Getting the graphics drivers out of kernel space is worth it – I know Vista got a lot of flak, but BSODs dropped basically to zero with the new display drier model.mitch074 said:Actually, since ReactOS uses Wine for API support the only reason they'd switch to Win10 as a target would be to isolate the graphics drivers from kernel space - as that's the main difference between the Windows Server 2003 kernel they're clean-room reverse engineering and the Vista/7/8/10 kernel.
Having it **look like** the patchguard etc stuff is implemented might be interesting for some usecases 😉mitch074 said:Maybe the scheduler...? But then they can swap a scheduler out and implement their own based on Linux ones as well.
I'm not so sure anybody would really be interested in all the entry points for spyware that Microsoft added later on, so... -
drivinfast247
Do you know what "iconic" means?Mark Knight said:The voodoo 5 cards were NOT iconic, they were a failure and put 3dfx out of business. -
mitch074
Driver out of kernel space : agreed. I'm not sure it's technically too difficult though, as the graphics driver were an exception more than the rule in NT5.x and older. Implementing WDDM on top of their kernel may not need that much re-architecturing.snemarch said:Getting the graphics drivers out of kernel space is worth it – I know Vista got a lot of flak, but BSODs dropped basically to zero with the new display drier model.
Having it **look like** the patchguard etc stuff is implemented might be interesting for some usecases 😉
Make it look like patchguard is working : in that case, Linux+Wine (or Proton) is a better approach. ReactOS is really looking at binary compatibility with drivers, so this may be an overreach.