vvbee wrote on 2025-01-13, 09:17:

Thanks for the testing. The readme goes into some more detail, but yeah, you need a non-NT Windows for Destruction Derby to work […]
Show full quote

Thanks for the testing. The readme goes into some more detail, but yeah, you need a non-NT Windows for Destruction Derby to work. I'm on Linux and only have modern Windows in virtual machines so no idea how well it works there. Doesn't seem work on Linux in Wine , but the wrapper in general does.

The wrapper uses the same video mode as the game, so 16 bits. Strange colors means pixels are being rendered with the wrong bit masks. They seem to vary from one video card to another, although the wrapper makes an attempt to figure out the correct one on launch. Maybe the auto detection is failing and the default isn't good for such and such card.

The S3d SDK looks to be using DirectX 1, which is probably about what the games are using as well. I'm not sure how easy that is to translate into hardware acceleration. Maybe you can do offscreen rendering into the legact DirectDraw frame buffer, no idea, no experience in this. It seems likely you'd have to wrap DirectDraw itself as well.

Here's another alpha for Destruction Derby with performance and visual improvements, though a few things don't render properly still. Maybe one of the changes happens to fix the color modes as well. It's again tailored for DD, so other S3d games will likely have more trouble than before. There's an optional debug DLL (rename it to s3dtkw.dll) that outputs runtime info, so run the game with "game > output.txt" to get the log. Basically any game where the wrapper fails to hook DirectDraw (i.e. because the game doesn't use it) isn't likely to work as far as I know.

Alright this release did a little better but in the starting video only, the menu still gets garbled again, although a Pentium 1 166 can only run the game at 2FPS 😀
Other games were tested on modern CPUs, so I think those games will have a better chance to run.

there is s3d api exclusive games: FX Fighter Turbo, Havoc , Screamer , Terminal Velocity, and some others can be considered as exclusive too , since they have other API's but they also din't wrapped.
you can look it all here
3D Accelerated Games List (Proprietary APIs - No 3DFX/Direct3D)

and even more details here:
https://gona.mactar.hu/3D/

more s3d games even discovered since then in vogons thread

RaVeN-05 wrote on 2025-01-13, 10:52:

there is s3d api exclusive games: FX Fighter Turbo, Havoc , Screamer , Terminal Velocity, and some others can be considered as e […]
Show full quote

there is s3d api exclusive games: FX Fighter Turbo, Havoc , Screamer , Terminal Velocity, and some others can be considered as exclusive too , since they have other API's but they also din't wrapped.
you can look it all here
3D Accelerated Games List (Proprietary APIs - No 3DFX/Direct3D)

and even more details here:
https://gona.mactar.hu/3D/

more s3d games even discovered since then in vogons thread

Yes I am using this list. There are at least 17 games here, 2 are unconfirmed (Toca and Des2 Inf Abyss). Out of which 7 are only Win32, 8 are DOS and 2 have both Win32 and DOS support.

There was also a Virge Quake I think

I tested FX Fighter and Time Warriors. both needed Handle Exceptions from DxWnd.

The colours are all messed up but the game runs.

In Time Warriors, in the fighting scene, the background keeps flashing.

In FX Fighter the menu elements are missing.

I think someone needs to do the DD work here since it probably is DX related?

"There was also a Virge Quake I think" - its just simple minigl driver which uses direct3d on virge surprisingly its speedups quake 1 on virge , but it doesnot do anything S3D API related, despite its official. also goes to atiquake (not related to ATI3DCIF)

About the Destruction Derby crash, the crash related to AYAPI.DLL also happened on a Stealth 3000 with vetz's executable. I don't know if it's the game's dll or the edited exe having some issue?

https://drew1440.com/2024/07/16/destruction-derby/

Nevertheless there needs to be some work done on the game to make the wrapper also more effective on different hardwares of that time

BEEN_Nath_58 wrote on 2025-01-13, 15:00:

About the Destruction Derby crash, the crash related to AYAPI.DLL also happened on a Stealth 3000 with vetz's executable. I don't know if it's the game's dll or the edited exe having some issue?

https://drew1440.com/2024/07/16/destruction-derby/

Nevertheless there needs to be some work done on the game to make the wrapper also more effective on different hardwares of that time

I think I tested those patches on two different Win98SE builds, a Pentium 3 and Socket 7. I remember the NOCD patch required more work than the card check and I was never able to bring back the music. I'm no expert in this, I just watched some videos, read some guides and did some trial and error for those hexcode changes.

RaVeN-05 wrote on 2025-01-13, 12:18:

"There was also a Virge Quake I think" - its just simple minigl driver which uses direct3d on virge surprisingly its speedups quake 1 on virge , but it doesnot do anything S3D API related, despite its official. also goes to atiquake (not related to ATI3DCIF)

There are two versions of these quake virge opengl-s, i have them both somewhere.

The color issue is mismatched pixel formats. In the screenshot with the funky ground the rasterizer uses the correct format while the blitter doesn't. I don't see this on my test systems (e.g. 86Box with ATI mach64 GX), but I've seen it during development. Mildly interesting trivia about Destruction Derby: the game doesn't really use the S3d API for rendering the ground, instead it looks to be applying a fake perspective skew to a bitmap and then submits that for rendering as a 2D image. This could look odd if you were to make a hardware wrapper with mipmapped texture filtering enabled, as the ground doesn't have actual perspective.

When you look at the small list of true Win32 S3d games it's hard to justify a wrapper for most of them. They tend to already have a software fallback as well as Glide and/or Direct3D, so not much point in wrapping S3d unless there's something special in that mode. Destruction Derby is an exclusive version at least, so to me it makes sense to have a wrapper that supports that game and then whatever custom S3d apps someone might write today following S3's spec. From what I remember Croc doesn't use DirectDraw, so that's a no go. The S3 "version" of GLQuake also didn't look to be using DirectDraw when I briefly tested it. There are a couple of API functions the wrapper doesn't expose that S3's s3dtkw.dll does, they're not supposed to be used for Win32 S3d but some games might still rely on them and have issues when they're not there.

If you run the debug DLL and direct the output to a text file it'll tell you the color format of the display surface somewhere near the top of the printout. Something like "[S3d2SW] Pixel mask: A=0 R=f800 G=7e0 B=1f." This would be RGR565 (default if no format is detected), and "R=7c00 G=3e0 B=1f" would be RBG555. If the format is reported in the output and it's one of those options then the color bug is in the wrapper code.

vvbee wrote on 2025-01-13, 18:00:

Destruction Derby is an exclusive version at least, so to me it makes sense to have a wrapper that supports that game

actually it has sega saturn and playstation versions that probably are already hardware accelerated and render in higher resolutions in their emulators

the windows ones that don't have are Havoc and FX Fighter Turbo (FX Fighter 2)

I think the only S3D games worthy of note are probably Destruction Derby, Screamer, and Fury3. It's great to see a wrapper for DD, just a shame that doing the same for DOS would be difficult. Perhaps a feature for a PC emulator like 86Box down the line.

Great job on this.

@vvbee This is the log from Time Warriors. The colours are scrambled and the log looks something like this:

Time Warriors looks to be testing a variety of resolutions and color depths, no idea what's up. Might not be getting the return values it's expecting.

I think the Destruction Derby AYAPI.DLL crash is due to a failure by the system to support the game's 512 x 384 mode and the game (or patch) not handling the DirectDraw error. I made a quick hack to the wrapper for testing purposes that forces the video mode to 640 x 480 instead. Works in a VirtualBox Windows 98 setup with the VBEMP 9x generic video driver at least, where otherwise the game crashes with the AYAPI.DLL error. You can test it out, maybe first set your desktop to 640 x 480 16 bits. In my VM the game then runs in a window-like box of 512 x 384,though the colors are messed up and the intro could use an FPS limiter. When I force the game's display mode to 24-bit I get what looks like a proper fullscreen 640 x 480 image, would just need to change the rasterizer to produce 24-bit color renderings and it might work alright, assuming the game itself doesn't try to read the image buffer.

vvbee wrote on 2025-01-14, 04:28:

Time Warriors looks to be testing a variety of resolutions and color depths, no idea what's up. Might not be getting the return values it's expecting.

I think the Destruction Derby AYAPI.DLL crash is due to a failure by the system to support the game's 512 x 384 mode and the game (or patch) not handling the DirectDraw error. I made a quick hack to the wrapper for testing purposes that forces the video mode to 640 x 480 instead. Works in a VirtualBox Windows 98 setup with the VBEMP 9x generic video driver at least, where otherwise the game crashes with the AYAPI.DLL error. You can test it out, maybe first set your desktop to 640 x 480 16 bits. In my VM the game then runs in a window-like box of 512 x 384,though the colors are messed up and the intro could use an FPS limiter. When I force the game's display mode to 24-bit I get what looks like a proper fullscreen 640 x 480 image, would just need to change the rasterizer to produce 24-bit color renderings and it might work alright, assuming the game itself doesn't try to read the image buffer.

Illegal operation:...

Too bad, although the idea is a kludge anyway.

What you can also do is modify the game executable (e.g. DD-NOCD.EXE) to change the hard-coded resolution to 640 x 480. Use a hex editor to change byte 0xb4be to e0 and byte 0xb4c3 to 80. There might be some other places too where it's hard-coded, but with this I'm seeing it working in VirtualBox (using the earlier versions of the wrapper, not the last one with the resolution hack), apart from various rendering issues.

vvbee wrote on 2025-01-14, 07:46:

Too bad, although the idea is a kludge anyway.

What you can also do is modify the game executable (e.g. DD-NOCD.EXE) to change the hard-coded resolution to 640 x 480. Use a hex editor to change byte 0xb4be to e0 and byte 0xb4c3 to 80. There might be some other places too where it's hard-coded, but with this I'm seeing it working in VirtualBox (using the earlier versions of the wrapper, not the last one with the resolution hack), apart from various rendering issues.

Used the prev alpha and the edit in the exe:

count the pixels 🤣

Looks odd. You can use the debug dll in alpha.2 to see what resolution the modified game is setting. If the output says "[S3d2SW] DirectDraw:SetDisplayMode(640, 480, 16)" then the right bytes were edited, otherwise not. I'm seeing more or less proper 640 x 480 rendering except for the ground, which the game itself renders into a texture outside of S3d, and that's a problem because it's not correctly matching it to 640 x 480 and more hex editing would be needed.

If my math is right, that's
640x331 - 256x31 =203904 raw pixels
(the game pixels - the non game rectangle)

Which... isn't a real resolution, but 576x354 is the closest to a real resolution

RichB93 wrote on 2025-01-13, 23:05:

I think the only S3D games worthy of note are probably Destruction Derby, Screamer, and Fury3. It's great to see a wrapper for DD, just a shame that doing the same for DOS would be difficult. Perhaps a feature for a PC emulator like 86Box down the line.

Great job on this.

the 86box or PCEm already supports various S3 Virge video cards, which offer S3D API to us, although can't confirm everything works, need tests, but having wrapper is more handy
as opposite to fully setup 86box and its long and inssifiend