Carmageddon (Win 95): problem with black bars in the in-game menu:

Carmageddon II: Carpocalypse Now (D3D mode): crashes on startup (APPCRASH).

Carmageddon TDR 2000: crashes on startup.

However, the game works when "Run in a window" is checked and "Mip Filter" is set to "None" in the game options (TDR2000.exe -setup).

Dege wrote:

I don't really understand it because I checked this game and it's indeed DX9.
Is there an earlier release using <=DX7 maybe?

There was an earlier freeware release which uses DX7 (I know because I also have a copy to test with): https://archive.org/details/La-Mulana

That's actually the most well known version.

As for why run it in dgVoodoo2: just looking for things that'll break dgVoodoo2. Also it runs horribly out of the box on Win8. That said, DXGL is probably the better choice for running it for perfect integer scaling of that pixel art.

Firtasik wrote:

Carmageddon II: Carpocalypse Now (D3D mode): crashes on startup (APPCRASH).

It's strange because it works for me with WIP9. (Carma2_HW.exe -D3D)

Firtasik wrote:

Carmageddon TDR 2000: crashes on startup. http://i.imgur.com/KyBx7R9l.png […]
Show full quote

Carmageddon TDR 2000: crashes on startup.

However, the game works when "Run in a window" is checked and "Mip Filter" is set to "None" in the game options (TDR2000.exe -setup).

I'm not sure but you should delete TDR2000.gfx to force the game to re-detect d3d devices at startup, through the wrapper.
It worked for me but the game crashed before entering the main menu. I found two bugs in dgVoodoo, one of them causing facepalm. Now that I fixed them, TDR2000 works beautifully.

There was an earlier freeware release which uses DX7 (I know because I also have a copy to test with): https://archive.org/details/La-Mulana

Ah, thanks! This game must be a very old one ported from DOS from the EGA display era with its 16 colors and brick-pixels. 😀

Dege wrote:

It's strange because it works for me with WIP9. (Carma2_HW.exe -D3D)

Now I know, it crashes because of a connected gamepad. 😵 Glide works fine with it, though.

Dege wrote:

I'm not sure but you should delete TDR2000.gfx to force the game to re-detect d3d devices at startup, through the wrapper.
It worked for me but the game crashed before entering the main menu. I found two bugs in dgVoodoo, one of them causing facepalm. Now that I fixed them, TDR2000 works beautifully.

Deleting TDR2000.gfx didn't help. It crashes when Carma's resolution is higher than 640x480.

Moto Racer 2 (D3D mode):

Broken minimap

D3D

DDraw

Garbled menus

GeForce 4 (Virtual 3D looks similiar)

Radeon 8500 (almost good)

DDraw

Requiem: Avenging Angel (D3D mode):

Version 1.2 (DX6):
"Sorry, DirectX 6 or later is required". Just like without dgVoodoo 2.

Version 1.3 (DX8):
Well, DirectX 8 is not supported by dgVoodoo 2. The game works, though. Low frame rate (Windows 8, I guess) and closing the in-game menu puts Requiem into something like windowed mode (Windows 8 again?).

Moto Racer 2 (D3D mode):

I changed the colorkeying shader code since wip9 so it's ok now.
Broken lines (minimap) are also fixed now, thanks.

It's an interesting game, it claims DX6 but uses execute buffers (DX3).

Requiem: Avenging Angel (D3D mode):

I don't know what the problem is but the game doesn't even make a single call into DDraw, just declares that DX6 required.
My tip is some direct checking of the DDRAW.DLL version, but didn't have a look into it.

Gho (dxwnd) about Requiem:

Another game oddity is the way it checks for DirectX version in the system: it looks for a registry entry and compares the version string with a series of possibilities, but obviously in 1999 nobody dreamt of DirectX 9 and the check fails

ZellSF wrote:

Gho (dxwnd) about Requiem:

Another game oddity is the way it checks for DirectX version in the system: it looks for a registry entry and compares the version string with a series of possibilities, but obviously in 1999 nobody dreamt of DirectX 9 and the check fails

😵 😵 😵
Then the game needs patching.

ZellSF wrote:

Gho (dxwnd) about Requiem:

Another game oddity is the way it checks for DirectX version in the system: it looks for a registry entry and compares the version string with a series of possibilities, but obviously in 1999 nobody dreamt of DirectX 9 and the check fails

That can be fixed by a "VirtualRegistry" compatibility shim with the parameter DX7A.

With dgVoodoo I can get to the menu but when I try to load a level the game crashes both in D3D and software mode. I couldn't install the game for some reason so I had to extract it manually. I don't know if that causes the crashes or dgVoodoo.

Edit: File deleted, use fix below.

teleguy wrote:

ZellSF wrote:

Gho (dxwnd) about Requiem:

Another game oddity is the way it checks for DirectX version in the system: it looks for a registry entry and compares the version string with a series of possibilities, but obviously in 1999 nobody dreamt of DirectX 9 and the check fails

That can be fixed by a "VirtualRegistry" compatibility shim with the parameter DX7A.

With dgVoodoo I can get to the menu but when I try to load a level the game crashes both in D3D and software mode. I couldn't install the game for some reason so I had to extract it manually. I don't know if that causes the crashes or dgVoodoo.

Wow!
Indeed, it crashes with wip9. But it works fine with the newest build, probably because of fixing the bug causing TDR2000 to crash.

However sotfware mode and 3Dfx still complain about DX6 for me.

Dege wrote:

However sotfware mode and 3Dfx still complain about DX6 for me.

Oops, a small mistake creeped into the file I uploaded.
Software mode should work now:

I've also added an uninstaller and support for 3Dfx (didn't realize 3Dfx.exe also checks for DirectX).

BTW the 3Dfx version is working great with dgVoodoo 1.

Dege wrote:

teleguy wrote:

teleguy wrote:

I noticed the resolutions in JK top out at 2048x1536 (the maximum earlier versions of DirectX allowed) with dgvoodoo but if I use WineD3D even the Downsampling resolutions I set up are available. Any chance support for higher resolutions can be added?

There's also an issue with the GOG version only showing the ModeX resolutions. I sent you a pm about it.

Any news?

I fixed '320x200 x-mode only' resolution problem in WIP9, but there is no 2048x1536 limit in dgVoodoo for resolutions.
All of them is enumerated that are coming from DX11. Do you get the missing resolutions in other DX11 games?

I looked into that.
With dgVoodoo and the Steam version of JK downsampling resolutions are only available when both Gpu Scaling and Virtual Super Resolution are enabled. If you use WineD3D or the GOG version of JK+dgVoodoo just Virtual Super Resolution is enough. Other DirectX 11 games I tested are not showing this behavior either.

On my nVidia everything seems to be fine.
Do you get the super resolutions in dgVoodoosetup? Or it all affects only JK?

Those resolutions are listed in dgVoodoosetup.

Dege wrote:

Ah, thanks! This game must be a very old one ported from DOS from the EGA display era with its 16 colors and brick-pixels. 😀

You'd think so, at least. Actually it's a game from 2005, designed to mimic MSX graphics. 😀

teleguy wrote:

BTW the 3Dfx version is working great with dgVoodoo 1.

Well, you always can patch the game to the version 1.3. This will remove the dx version check.
Unfortunately there is 1 glitch in WinXp and later. The font size is bigger so some text strings are trimmed (display/sound options as the example).
Tnx for the info about the VirtualRegistry DX7A ACT fix. I will add it to my nGlide test pack.

Might and Magic 7 with 2.44 and WIP9: The dgVoodoo watermark is always visible. Otherwise seems to work great--it corrects the common problem of the screen continually flashing white in D3D mode.

ZellSF wrote:

I don't have it installed at the moment, but did you figure out what was wrong with Breath of Fire IV?

Now I figured it out. It doesn't clear its surfaces after allocating them but simply supposes that they get created zeroed out.
I checked my theory by filling every surfaces with white at creation, and the text corruptions become white too.
So I fixed it but it is an application side bug as DDraw is not expected to provide a zeroed out initial state.

galneon wrote:

Might and Magic 7 with 2.44 and WIP9: The dgVoodoo watermark is always visible. Otherwise seems to work great--it corrects the common problem of the screen continually flashing white in D3D mode.

Great! I hope I won't break it.
Don't you run this game in compatbility mode causing it not to find the configuration file but use the default and that's why the watermark is always visible?

Ahh, that was exactly the issue. I'd forgotten to remove compatibility mode when I added the wrapper. It isn't necessary with the wrapper. Thanks!

Deus Ex now works using WIP9, but using either a virtual GeForce or ATI card introduces some issues with transparencies, which affects 3D and 2D objects (mainly the inventory objects) differently.

3D objects with broken transparencies merely require a scene reload.

2D objects require a complete level change, and do not go away by reloading the current level. As such, this issue can be captured in a save file (see attachment, was using the virtual ATI card).

Also, Empire Earth and its expansion still experience the same issue from WIP8 when using WIP9.