Keep in mind it's a game from 1996, by default it probably won't work on newer Windows. The error is saying something is accessing a null pointer, probably some initialization failed and there's not enough error checking in the program to handle it, wherever that might be.

The error generally would lean towards the heap issue. Try using Windows ADK and enable the EmulateHeap shim over the executable.

Generally Windows 95, 98/ME compat mode would do that work, but either other shims in the modes are stopping the game from running, or it is the natural behaviour with EmulateHeap in the game

The first post has been updated with beta.3.

This version adds a 320 x 240 render mode (upscaled to 640 x 480 for display), centers the 512 x 384 letterboxed mode, and fixes an occasional frame hickup. The in-game UI scaling at 320 x 240 isn't too great, but not impossibly bad.

In 86Box, the 320 x 240 mode is just about playable on a Pentium MMX 200:

So within the space of a week the minimum playable requirements went from a Pentium 4 to a Pentium 1.

I currently don't have access to a machine for Win98, but I was able to test the other games with the beta 2.

In FX Fighter at least, the cursor was now visible in a skewed? form. In Crocs, some graphics in the intro were visible.
Time Warrior no longer works.

The less well they work the better for this DD optimized version. Croc doesn't use DirectDraw for S3d so it wouldn't be supported by this anyway. The intro is something else. The game uses VRAM directly like DOS S3d does so you'd need to implement some device independent way to display the output while still directing input to the game etc. Maybe there's a way and maybe not, as pointless as it is.

The beta phase is now over. The first post has been updated with the first regular numbered version.

For Destruction Derby, some bugs were fixed and performance was improved somewhat. Some INI options changed place or were added.

The first version of the reference wrapper was added. It's a generic software wrapper for S3d version 2.6 for Windows, intended as a tool for developers who are writing S3d software in the present. It doesn't support old S3d games that don't conform to the 2.6 spec. Requires a fast, modern CPU.

would be cool if someone, i mean backport PCEm or 86Box s3 Virge emulation to dosbox, so dos games and win95 under dosbox can use s3d api in software renderer mode, dosbox more useful and works faster and easier to setup than LLE emulators. like 86Box or PCEm.

even if in future someone can use hardware acceletration, will became even ore superb, as with it can be archieved fast performance, and high resolutions with other advance features.
All that just ideas now.

Thanks for vvbee for your great work and dedication )

That's looking great!

vvbee wrote on 2025-01-19, 17:57:

On XP the game should work with the DxWrapper settings from the readme and Windows 9x compatibility mode. Same thing on Wine, need to set the Windows version to 9x.

I have found the way to run it. At least on my system (Intel Atom N280, Intel GMA 945, Windows XP) I have to leave Dd7to9 = 0. If I change it to 1, the game crashes after the intro.

I can run the game just fine without changing compatibility mode or HandleExceptions = 1.

First post updated with v.2.

Large performance improvements. Some visual artifacts fixed. Added a tracer wrapper, which output an application's S3d and DirectDraw call trace into stdout and does nothing else. If the call trace says nothing about DirectDraw then you know the game probably won't work even in theory.

ntalaec wrote on 2025-01-22, 19:26:

vvbee wrote on 2025-01-19, 17:57:

On XP the game should work with the DxWrapper settings from the readme and Windows 9x compatibility mode. Same thing on Wine, need to set the Windows version to 9x.

I have found the way to run it. At least on my system (Intel Atom N280, Intel GMA 945, Windows XP) I have to leave Dd7to9 = 0. If I change it to 1, the game crashes after the intro.

I can run the game just fine without changing compatibility mode or HandleExceptions = 1.

Probably you set Windows 95 compatibility. The error you mentioned above used to come from the lack of the Win9X heap system. I can try it now

BEEN_Nath_58 wrote on 2025-01-23, 11:57:

ntalaec wrote on 2025-01-22, 19:26:

vvbee wrote on 2025-01-19, 17:57:

On XP the game should work with the DxWrapper settings from the readme and Windows 9x compatibility mode. Same thing on Wine, need to set the Windows version to 9x.

I have found the way to run it. At least on my system (Intel Atom N280, Intel GMA 945, Windows XP) I have to leave Dd7to9 = 0. If I change it to 1, the game crashes after the intro.

I can run the game just fine without changing compatibility mode or HandleExceptions = 1.

Probably you set Windows 95 compatibility. The error you mentioned above used to come from the lack of the Win9X heap system. I can try it now

The problem is solved with the Ignore Exceptions shim in ACT. The game now runs fine on my XP too

First post updated with v.3.

Adds a FRAPS-like FPS overlay wrapper for Win32 S3d, requires an S3d card. The tracer will now pass S3d render calls to the driver if there's an S3d card present, so you don't have to look at a blank screen.

For some games the FPS overlay works alright. For MechWarror 2 it's so so, maybe you'll get some useful readings here and there. Different games use different methods. Like FRAPS it has an effect on performance, but I haven't looked into it.

Updated with v.4.

Added a software wrapper for Havoc. Supports bilinear texture filtering but not mipmaps. Requires a CPU with SSE, but probably Pentium 4++, haven't tested it much.

FPSCounter is less conservative about redrawing itself. Will result in the counter flickering more in some games, e.g. Croc. See workarounds in the INI. Now works in Havoc.

Trace renamed CallTrace, in the INI as well.

Updated with v.5.

Added a software wrapper for POD. Far as anyone knows, this game uses S3d only for shadows, skidmarks and smoke, the rest is CPU. That makes this a unique version of the game, software renderer with true alpha blending.

Fixed some missing alpha blending in Havoc. Based on my real world testing, you'll want an Athlon 64 ~3 GHz or equivalent for decent FPS.

The FPS counter was improved for MechWarrior 2. I verified using my capture software that the FPS value is accurate, at least for the 30 seconds of gameplay.

Am I correct in noting that you've basically matched the performance of the card on era appropriate hardware?

The card is faster for sure. But the fact that POD chose to use it only for shadows etc. makes me think they realized a full S3d version would've been noticeably slower than their software renderer. Still, the fact that they used it for alpha blending would suggest it's faster than software, if they weren't just bound by contract to make something for S3.

The S3d API has some support for multithreading. I haven't used it and don't know the details, but I wonder whether you couldn't have one thread call S3d render functions and another thread doing extra software rendering while the card is rasterizing. Like Destruction Derby with its software generated mode 7 terrain and POD's everything but shadows on the CPU.

Updated with these changes:
- Havoc's pre-game menu now displays more or less correctly
- Havoc performs about 20% faster
- FPSCount was renamed FPSOverlay

Updated to add a Glide-to-S3d wrapper for Glide 2.4. Alpha stuff and will make your system unstable. Based on my brief testing it may run 30-40% of Glide 2.4 games, and 10-20% of them might be playable with minor glitches only. Perspective correct texturing is disabled for all of them, but looks worse in some. See the readme before you go running it.

Tested exclusively in 86Box, but Ignition was also tested on a real ViRGE/DX. Didn't work with the 3.42 drivers but did work with 3.12, might've just been a bad driver install. Runs at a decent FPS actually, for what it is, long as you don't care about image quality.

this reminds me BiGRRed https://www.vogonsdrivers.com/getfile.php?fileid=167
which is Glide -> RRedlline API wrapper.
anyway i think you already knows those all have wrappers too RReady (Rendition Verite wrapper) Test Build (Alpha 1)

P.S. Source if interesting https://www.vogonsdrivers.com/getfile.php?fil … &menustate=17,1