myne wrote on 2025-01-14, 09:24:

count the pixels 🤣

Closesly, I can see 3/4th of 640x480 but with repeated images 🤣

vvbee wrote on 2025-01-14, 09:32:

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.

I think it is edited correctly, I have attached the log. However the multiple images is also an issue now.

The ground textures are outside of S3D, DirectDraw then? Did all games subject to using DirectDraw with S3D or they mixed it up with other APIs and GDI?

robertmo3 wrote on 2025-01-13, 20:12:

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)

Havoc crashed at a GetDisplayMode error. FX Fighter runs but the background flashes and the colours aren't right, maybe DD related

Strange that. I see the 640 x 480 mode correctly in VirtualBox and 86Box, but in Wine on Linux just a blank screen, though the game runs. Still, it fixes the AYAPI.DLL crash, so seems like that's caused by 512 x 384 not being a supported mode on the system. I thought it'd be more widely supported, but who knows. It may also be a refresh rate issue, but I'm not sure how the refresh rate was set in the early DirectDraw days.

S3d is a mix of DOS and Win32 functionality. In Win32, games are supposed to use DirectDraw to manage video and texture memory, in DOS they access VRAM directly. The S3d API doesn't force the choice. From what I remember, Croc for example has a stub s3dtkw.dll that only exposes partial API functionality. Maybe they didn't have time to finish porting it to Windows or whatever.

I think upping the Destruction Derby render resolution to 640 x 480 may be a backburner idea. From what I can see the game may be rendering the ground properly but the source texture data for it is only good for 512 x 384, the texel reads end up picking up other textures and the result is a mess. Nothing to do with S3d, the game uses its own 2D algo for fake perspective baking and you'd have to modify some angle to this in the executable.

Probably the frame rate was just put to how fast the CPU/GPU can? Or maybe reading the monitor refresh rate? Or something like:
https://steamcommunity.com/app/227600/discuss … 79008327344181/

512x384 is a supported mode on my Win7 (in 16bit as well) and Win11 system (other DX emulators expose 16bit colour too) so it shouldn't be that.

If emulating a system isn't an issue, then I am using a P166 with Voodoo3, with DX7 installed (mentioning this bit since DX8 made the system unstable, with the same multiple image effect in almost all DX apps).

Alternatively we can look into other games, but Idk if there's anything to fix unless you couple up DirectDraw.

Btw is the project closed source? I am no programmer, but there could be anybody wanting to help with DX part?

Wasn't your system getting an AYAPI.DLL crash before changing the hard-coded resolution? It's what I saw in Wine and VirtualBox anyway, so a fix on some platforms at least.

If someone can make a patch or workaround for the game that makes its terrain algo resolution independent then I think that would be key to getting it running on more systems. As far as I can see it's 100% in the game and outside of S3d's control. There are now various ways to have the game running in other video modes, I had it happily at 1024 x 768, but unless the terrain algo gets with it it's going to be a problem. Not easy though unless you have solid experience in reversing and assembly.

The project is closed source, I'm just doing it for fun.

vvbee wrote on 2025-01-15, 01:52:

Wasn't your system getting an AYAPI.DLL crash before changing the hard-coded resolution? It's what I saw in Wine and VirtualBox anyway, so a fix on some platforms at least.

If someone can make a patch or workaround for the game that makes its terrain algo resolution independent then I think that would be key to getting it running on more systems. As far as I can see it's 100% in the game and outside of S3d's control. There are now various ways to have the game running in other video modes, I had it happily at 1024 x 768, but unless the terrain algo gets with it it's going to be a problem. Not easy though unless you have solid experience in reversing and assembly.

The project is closed source, I'm just doing it for fun.

S3DStW.DLL crash. The AYAPI.DLL crash happened for others in Win98, and here on modern systems, and still crashes nevertheless.

On the systems I've tested, only VirtualBox and Wine had the dll crash, both were fixed by editing the resolution, and in the case of VirtualBox I know from debugging that SetDisplayMode returned an error which confused the game or booted it onto a DOS render path. In 86Box I haven't seen the dll crash and on my Athlon 64 Win 98 system with ViRGE/DX it worked fine as well.

The main problem I'm seeing with the game is the blank screen in Wine. I know the wrapper works in Wine because my own S3d renderers and S3's render samples work, using some unreleased generic versions of the wrapper. The game is likely doing something odd. In fact I almost think there's a binary incompatibility because at times it looks the game is feeding uninitialized data to the wrapper. I don't think I've seen an S3d game yet that follows S3's final spec on S3d anyway, which is to say the API never stabilized.

just a question:
if the game already works in very high resolutions in duckstation, so why bother with s3d just for this game?

You have the wrong idea if you think this is just for playing DD. But even for that this is closer to era correct than a PS1 emulator.

Here's how the game renders the ground (turning left):

It's basically doing a mode 7 in software, then asking S3d to blit that to the screen before rendering the track's polygons on top. The parameters for the image generator look to be hard-coded for 512 x 384 but it'll be generated at whatever resolution is being used, so unless that behavior can be changed in the game's executable the best that could be had is to try and fool the game into thinking the current mode is 512 x 384 and then upscaling the ground image it creates.

I also found that Wine does display an image, but only e.g. when pressing ESC during a race. So the problem has something to do with the display surface not being updated in the meantime. Also, looks like Wine can run the game at 512 x 384 even if the monitor or video card doesn't support the resolution, by using the virtual desktop.

what if you can intercept that blit and upscale it on wrapper (as a 2d image ) resampling from original size to what ever you want, than finally blit?

RaVeN-05 wrote on 2025-01-16, 10:26:

what if you can intercept that blit and upscale it on wrapper (as a 2d image ) resampling from original size to what ever you want, than finally blit?

They wrote previously they aren't getting into the DX part (at least for now) so it remained untouched...

It can be intercepted, the series of images is a direct capture of it. Problem is the game renders the image wrong if the resolution isn't 512 x 384, so you'll just capture a corrupted image. It seems possible the game is pulling the resolution from the size of the primary DirectDraw surface, which has to be the size of the desktop even in windowed mode, so it's difficult to avoid having to enter the 512 x 384 video mode at any point. But maybe there's a way. Or maybe there's a way to reconstruct the corrupted image, since it's known what the two resolutions involved are, and if you can guess the memory access patterns.

It seems possible to reconstruct the 512 x 384 terrain image from the mangled higher-resolution version.

The first image is at 640 without reconstructing, the second has reconstructed it, and the third one is the reference look at 512.

I'm not an image processing expert but to me it looks like the game generates the image at 512 x 384 and then mangles it when copying it to the output buffer with mismatched resolutions. It's not just a linear copy of 512 pixels onto 640, looks like 2D indexing with the wrong dimensions, but I don't recognize the type of artifact. Not sure which operation would generate empty rows in this context.

The alpha phase is over, thanks to all testers.

The first post has been updated with the file for beta.1. It adds some features that you can customize via an INI, which you should read. Support for Destruction Derby has been improved, but the game likes to do its own flip chain management behind the scenes and so flicker remains a problem. Seems worse on some systems and nonexistent on others. It does now display an image in Wine as well, but with issues.

The first post has been updated with beta.2.

I believe I've generally solved the flickering issue. Render performance may or may not have improved. There's a new option for the 640 x 480 mode to upscale the rendering, not just letterbox the 512 x 384. Some other changes. Some graphical glitches are there as well. See the INI file for what options have been added and which have been removed.

Beta.1 was compiled with Pentium 2 level optimizations, but they may not be well supported on AMD. This version is again compiled with the slower Pentium level optimizations, losing some FPS. I think a Pentium 2 is the minimum level for playable FPS in any case. The game is capped at 23 FPS so it's not too hard to max out, maybe a Pentium 3 would do it.

On my K6-2 300 I get about 7 FPS:

With beta 1 I was able to run the game but with severe graphic glitches. With beta 2 I'm able to load the logos and the intro without graphical issues but after the intro the game freezes. It does not show the menu.

I'm using VideoMode640x480 = 2, Windows XP, Intel Atom N280, Intel GMA 945 and last version of DxWrapper for Windows XP.

If I don't use DxWrapper and I use "ShowDebugOSD = 1" I get an error dialog: An privileged instruction was executed at address 004177c8.

ntalaec wrote on 2025-01-19, 10:47:

With beta 1 I was able to run the game but with severe graphic glitches. With beta 2 I'm able to load the logos and the intro without graphical issues but after the intro the game freezes. It does not show the menu.

I'm using VideoMode640x480 = 2, Windows XP, Intel Atom N280, Intel GMA 945 and last version of DxWrapper for Windows XP.

If I don't use DxWrapper and I use "ShowDebugOSD = 1" I get an error dialog: An privileged instruction was executed at address 004177c8.

What's the last DxWrapper for WinXP? I would want to test

BEEN_Nath_58 wrote on 2025-01-19, 11:10:

What's the last DxWrapper for WinXP? I would want to test

https://github.com/elishacloud/dxwrapper/releases
It's the winxp.binaries.zip file.

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.

Something really wrong happened here (beta 1 and 2)

This popup with and without dxwrapper.
If I enable win95 compatibility and I run DD-NODIAMONDCARD.EXE nothing happens.

I'm on win10 x64, Ryzen 5 PRO 4650G, 8gb ram.