Looks like the Glide-Verite wrapper guys had the same problem with paletted games like Ignition, need to convert the textures into 16 bit and then the 4 MB of video memory isn't enough. Too bad that's where the ViRGE tops out, then you're spilling into slower system memory. The S3d API supports paletted textures but doesn't actually have any documented mechanism to set the palette, oops. Might work through DirectDraw but might also be limited to 8 bit video modes.

Updated with some improvements to the Glide-S3d wrapper. About 60-70% of Glide 2.4 games might now run to some extent, still probably only 10-20% are playable. Some extra CPU overhead now, performance might be down.

Ignition works better now, with some issues still. Might make sense to write a separate optimized wrapper for it, since it's one of the few Glide only Windows games.

Some interesting glitches in various games. No idea what's going on in Monaco Racing Sim 2 for example.

That looks like some kind of mask to separate where the sky, land, hud, and cars should be drawn.

Ie, one of the hidden processes rendering uses to sort the graphical data.

Could be, though in this case it may be something else. The game can also look like this and run at 0.1 FPS:

Not all Glide functions have been implemented in the wrapper, so it's not surprising that there are glitches. But it's interesting how some games can work almost perfect while many are completely broken. I think it's the unfortunate situation of Glide providing multiple ways to do more or less the same thing.

vvbee wrote on 2025-02-07, 10:34:

Updated with some improvements to the Glide-S3d wrapper. About 60-70% of Glide 2.4 games might now run to some extent, still pro […]
Show full quote

Updated with some improvements to the Glide-S3d wrapper. About 60-70% of Glide 2.4 games might now run to some extent, still probably only 10-20% are playable. Some extra CPU overhead now, performance might be down.

Ignition works better now, with some issues still. Might make sense to write a separate optimized wrapper for it, since it's one of the few Glide only Windows games.

Some interesting glitches in various games. No idea what's going on in Monaco Racing Sim 2 for example.

This is really cool, it's great to see some more stuff accelerated in S3D - especially Ignition; what a great game! When I'm back home I'll give this a go on my STB Nitro 3D.

Keep in mind you need to skip the intro cinematic in Ignition or you get a system freeze. Later on I'll put out a separate version for Ignition, with somewhat improved alpha blending and some other things.

I may do that in general, there's not much point in having a general-purpose wrapper when most things don't work. Would be better to have hand-crafted versions for games that the ViRGE has a chance of running in the first place. Apart from being slower it only has a fraction of the features of the Voodoo, so most things would never run well enough. You could render unsupported features with software, but at that point might as well make a software wrapper.

Updated with some updates to the Glide wrapper, and to add an optimized Glide wrapper for Ignition. There's now an INI file with options to tweak. For most games you'll want to disable perspective correction until you know the game runs, S3d seems to be more fragile in that mode. For paletted games reduce texture resolution by one step for 4 MB cards and two for 2 MB.

For Ignition there were some performance improvements, alpha channel stippling is now used to emulate an unsupported blending mode, and it'll auto detect VRAM size to scale texture resolution and support 2 MB cards. 4 MB cards will have half the texture resolution of the Voodoo, and if the Trio3D supports S3d well enough to run this then an 8 MB one would get Voodoo res. I want to test this wrapper on real hardware at some point, seeing some slowdowns in an emulator and it may happen on real hardware as well. I think the software mode looks the best out of all, but whatever.

Monster Truck Madness 2 (demo) now runs, previously it froze the system on frame #1. Somewhat slower than Direct3D and perspective correct texturing likes to freeze, but it also doesn't have the alpha glitches of the D3D version, which is interesting.

Hello everyone! Thank you very much, vvbee, for this project, and congratulations for your work. It is always amazing to see new projects of this kind.

I spent some time debugging Destruction Derby and, despite my limited skills, I made some interesting discoveries I want to share with everyone in this thread.

In first place, I made a proper No-CD patch that retains the ability to play music tracks from any inserted CD-ROM, either on a real unit or a virtual one. Of course it still works with no CD-ROM inserted and even if the system has no CD-ROM units at all (the original patch fails to launch in this case). It can even be used with a winmm wrapper to play the tracks from ripped files on the hard disk, I tested it with the one included in DxWnd (which is, by far, the best that I'm aware of).

The following patch is mean to be applied to the original DD.exe executable from the CD-ROM, or the No-Diamond patched one. Do not apply it to the old No-CD patched one, it won't work as expected. With an hexadecimal editor, make the following changes:

• At 0x786F change 55 89 E5 with 33 C0 C3
• At 0xB293 change 75 5E with 90 90

In second place, I made a patch that allows the game to be executed on Win10/11 (XP should work t0o) without requiring the handle exceptions trick from DxWnd/DxWrapper or the IgnoreExceptions compatibility shim. Upon launching, the game tries to execute some CLI/STI instructions, which are privileged ones, and should never be executed by userland processes (Windows 95 was crazy times). The following patches NOP these instructions, preventing the exception that makes the game crash:

• At 0x25782 change E8 41 24 FE FF with 90 90 90 90 90
• At 0x258FF change E8 C6 22 FE FF with 90 90 90 90 90

The above patches, combined with WineD3D 10.1 as DirectDraw wrapper and the s3dtkw.ini file configured at 640x480 and limited to 60 fps, allows the game to be run on Win10/11 flawlessly. I tested it on Win10 22H2 with modern hardware (Intel Gen 12th CPU and a 4070 GPU) and a Win11 VMware virtual machine, and everything seems to work fine.

If the game crashes at launch with a memory write error, disable any compatibility modes that could be enabled. If the problem persists, try to rename the executable to anything else, as sometimes Windows insists to automatically apply compatibility settings (specially if the process crashed before).

DDrawCompat 0.5.3 can also be used instead of Wine3D3, but it has a very annoying issue. Sometimes when loading the menu or a race, the image freezes but the game continue to work in background (you can tell by the sound and game responding to key presses, but the image stays still). When this happen, press shift+f11 to enter the DDrawCompat setting menu and change the RenderColorDepth parameter to any other value, this will temporarily fix the issue until the next race is loaded.

Also tested dgVoodoo and CnC-DDraw, both of them cause a memory write error at launch. This is probably easy to fix, but I have no DirectX skills, so I can't debug it. Anyway, WineD3D seems to work perfectly.

If anyone tries any of the above patches, It would be great to have more feedback.

Sounds useful. I'm burnt out on Destruction Derby for the moment, but no doubt someone'll give it a spin.

Updated with changes to the Glide wrapper, don't remember exactly what. Need for Speed 2's menus are no longer corrupted, Die by the Sword now runs (sans menus). Need for Speed 2 is in fact playable, just with a ton of glitches. GLQuake with MiniGL 1.49 runs again, same with Redline Racer. This is in 86Box.

I tested the Ignition wrapper on a real 2 MB ViRGE, fairly high clocked. With texture filtering and perspective correction off I get a decent 25-35 FPS, otherwise around 15-20. But this is on a fast system, there's probably some extra CPU overhead still in the wrapper, and some unnecessary S3d state changes etc.

Unlike in 86Box and I maybe on my ViRGE/DX, the ViRGE couldn't render the stippled alpha correctly, just lots of white dots all over. In fact it seems to render all "transparent" areas white instead of black when texture filtering is enabled. So I added an INI option to disable the stippling.

Updated with changes to the Ignition wrapper. Improved performance, reduced texture seams, and brought back some particle effects that are broken in the native Glide version. Strange the particles were never fixed, the Glide version totally lacks all water and spark sprays as far as I can see. But it looks like the game just forgot to shift down fixed point vertex coordinates for them.

Updated with changes to the Ignition wrapper. There's now a choice between 640 x 400 and 320 x 200, as well as 24 bit modes for each. Also an extra performance option to cull alpha effects.

On a 2 MB ViRGE I get a fairly solid 35 FPS (half the refresh rate) at 24 bit 320 x 200 with bilinear filtering and perspective correction.

With 24 bit support and fixed particle effects, this S3d version is now better than native Glide in several ways.

I've seen the emulated Trio3D/2X fail to run S3d in Windows, and now that I had a chance to test my real one it also fails. In fact it fails just like the emulated one, when attempting to initialize the S3d library, so it's not the case that it doesn't support some particular functionality of S3d but rather it just doesn't have any chance of working because it can't initialize.

I've seen conflicting reports on this. Some say the Trio3D doesn't support S3d while the Trio3D/2X does, etc., but with this particular model and the couple drivers I tried the 2X doesn't seem compatible. Maybe it works for DOS S3d, maybe really old drivers work, maybe earlier revision chips work, etc. The drivers do bundle s3dtkw.dll, which would be pointless if the card doesn't support it.

Updated with changes to the Ignition wrapper. Added support for chromakey transparency and 4-bit alpha blending, with and without dithering in the texture conversion. So now it's a choice between chromakey + alpha test, alpha test + stippled blend, or 4-bit blend. Can't have it all. Maybe I'll get around to testing paletted textures, but I think the technical manual for the ViRGE chip mentioned no alpha or filtering support on 8-bit textures, so that's not too good. Maybe the DX/GX/VX/MX etc. relaxed those limitations.

Updated with changes to the Glide wrapper:
- Custom video modes
- Added some more unimplemented LFB stuff
- Perspective correction automatically disabled for polys with out of range UV coordinates, to prevent freezing
- Some other things

The Grand Prix Legends demo is now able to display the title card before freezing. POD has working menus. GLQuake has better font rendering.

Monster Truck Madness 2 may be the next one that gets a custom optimized wrapper. The wrapped Glide version looks better than the Direct3D one, though maybe older drivers work better. Actually in the wrapped version the glitches are inside the cockpit while in the D3D version they're outside. Textures look a tad brighter in the Glide version, which is interesting. I remember hearing something about the 3dfx version having something different about the textures, but can't remember what.

Updated with a separate wrapper for Monster Truck Madness 2. Fixes the HUD, adds fog, and whatever. Also runs on a 2 MB ViRGE, I don't think the game supports sub-4 MB cards by default so another bonus. Haven't tested it on real hardware but I'm sure it's about the same as emulated.

The reference Glide wrapper was also updated, but can't remember what with. Maybe some LFB stuff.

Good morning
is it possible to add support s3d acceleration with terminal velocity ?

Probably not, as it dos game.

Updated with a Mystique-to-S3d wrapper for Destruction Derby 2. Alpha version.

At best works to some extent, typically is mostly messed up. The Mystique supports 4 bit paletted textures and the game makes heavy use of them + different palettes for different regions of texture atlases + the MSI API has no control over VRAM writes or texture uploads. Not good for the ViRGE, but it may be possible to support this game well at some point.

Any luck with this on Crime Cities? It has a s3dtk minigl of its own (which can be tossed at other games like Quake3 with funny results 100% related to not blendfunc'ing, not clamping and not modulating, but there's opportunistic detemination to writing a source port that can fix all of this with preprocessed texture loading to work around various deficiencies that brian hook didn't bother with)