Never mind, compatibility fixes have nothing to do with it, it's a bug in MAX-FX engine's handling of multiple displays (or graphics cards?). It's only picking up the resolutions of my secondary monitor, which is smaller. It gets confused because it thinks it picked 2 different graphics cards, but it actually got one with 2 monitors plugged to it. It doesn't differentiate between different monitors, just graphics cards. And dgVoodoo apparently gives DISPLAY# string instead of GPU name so it works with that, it only gets confused with multiple same names. The difference between the games and the benchmark is, in games, I can still pick the right adapter/resolution by selecting another entry in the drop down list, but that doesn't seem to work in 3DMark. Regardless of what I click, I get resolutions of my secondary monitor.

This list doesn't make much sense, does it?

VirtuaIceMan wrote:

Here's a large collection of older PC racing game screenshots I took, upscaled using a mix of dgVoodoo and nGlide: http://forum.arcadecontrols.com/index.php/top … c,152678.0.html

Wow, nice collection...!

SpooferJahk wrote:

Advent Rising Broken Shadows

Wanted to leave the thread I posted but I wanted to bring up another game that is forked over with modern hardware for lacking some buffer hardware, Advent Rising. Apparently the game was broken even at the time was released with the shadowing system on anything but an ATI card. I have tried dgvoodoo2 with this title and it does not really do anything outside of making my game lag a bit but wanted to bring this up so maybe Dege can implement support from the shaders that the ATI 9800 supported.

stranno wrote:

Dakar Rally, another obscure japanese rally game with japanese error message. […]
Show full quote

Dakar Rally, another obscure japanese rally game with japanese error message.

Same error with DXWnd.

DirectX 3 game, pretty old. It is, quite probably, Playstation HLE emulation. You can turn on "emulation" in registry and it looks exactly the same as the Playstation game.

Thnaks for the reports.
Unfortunately I still need some time to finish basic refactoring.
Until that, I don't see the point of fixing bugs or developing new things because remaining part of the process may ruin them.
(Altough it's a very important aspect for me to always keep dgVoodoo in operable state and continuously do a lot of testing.)

lowenz wrote:

dgVoodoo 2 has a problem with Chrome engine 1 (Chrome and Chrome SpecForce) […]
Show full quote

dgVoodoo 2 has a problem with Chrome engine 1 (Chrome and Chrome SpecForce)

fmt: X8R8G8B8
1728x1080, bpp:16, hz:60, fmt: R5G6B5
1728x1080, bpp:24, hz:60, fmt: X8R8G8B8
CAPS: MaxSimultaneousTextures 8
CAPS: MaxTextureBlendStages 8
FATAL ERROR: Cannot find valid frame buffer format!

(1728x1080 is my custom 16:10 resolution, declared through NVidia Panel)

Yes, it's because of 24bit render buffers or sg like that afair.
Back then I had to install some of the game patches to cure that.

UCyborg wrote:

But there's no guarantee it will work flawlessly forever with original DLLs. The risks associated with doing heavy stuff in DllM […]
Show full quote

lowenz wrote:

I use crosire d3d8to9 for Max Payne 1&2. It works flawless.

But there's no guarantee it will work flawlessly forever with original DLLs. The risks associated with doing heavy stuff in DllMain have been known forever, but Remedy guys haven't considered that, and few years later, things started to break. It still seems to work flawlessly on NVIDIA out of the box, at least on 368.81 drivers, but again, there is no guarantee this will always be the case.

In such cases, some people love to blame Windows, drivers etc. because it happened to work on early versions of those, only careful examination reveals the actual culprit.

lowenz wrote:

UCyborg wrote:

PS: Max Payne 2 doesn't use d3d9.dll at all for rendering, it just loads it very early, does some queries or something, unloads it, then everything is driven with d3d8.dll

Exactly.

Right, should've quoted dege's original post. 😁 I wrote that because he stated at one point that Max Payne 2 uses D3D9 runtime, but only utilizes D3D8 level features and I've noticed that d3d9.dll is already gone from the process by the time configuration dialog shows up, though indeed it does actually make some calls to d3d9 before that. Perhaps this is why MP2 takes noticably more time to launch then MP1? At least that's what I notice on my PC.

Hmm... it's interesting. I should revise MP1&2 then.
I remembered that MP1 is DX8 but is of the initializing-from-DllMain type, while MP2 is DX9, so dgVoodoo is unusable for them.

UCyborg wrote:

Patch for 3D Mark 2001 SE done so it can run via dgVoodoo as well: 3D Mark 99 Max & 2001 SE Startup Hang Patch On 6th test, it t […]
Show full quote

Patch for 3D Mark 2001 SE done so it can run via dgVoodoo as well: 3D Mark 99 Max & 2001 SE Startup Hang Patch
On 6th test, it throws this error: P_D3D::DRV_allocateMap - device does not support bump normal maps

Also, Windows applies some compatibility workarounds to the executable to prevent it from crashing as apparently the program does something ugly. One of those fixes is apparently the one that limits number available of available resolutions, so when run via stock d3d8.dll, only first few resolutions are available. Would be cool if someone figured out a patch to make it run flawlessly without those compatibility workarounds.

3DMark2001SECompat.png

It sounds fabulous! 😎 I'm going to try it right now! I struggled a lot to run it on Win7 back then, without any success.

UCyborg wrote:

Never mind, compatibility fixes have nothing to do with it, it's a bug in MAX-FX engine's handling of multiple displays (or graphics cards?). It's only picking up the resolutions of my secondary monitor, which is smaller. It gets confused because it thinks it picked 2 different graphics cards, but it actually got one with 2 monitors plugged to it. It doesn't differentiate between different monitors, just graphics cards. And dgVoodoo apparently gives DISPLAY# string instead of GPU name so it works with that, it only gets confused with multiple same names. The difference between the games and the benchmark is, in games, I can still pick the right adapter/resolution by selecting another entry in the drop down list, but that doesn't seem to work in 3DMark. Regardless of what I click, I get resolutions of my secondary monitor.

MP1Dialog.png

This list doesn't make much sense, does it?

Well, in DX<=9, a device corresponds to a monitor. Even if you have 2 monitors attached to the same video card, they still appear as 2 separate devices in old DX. (XP DX9 had fullscreen-only support for dualhead videocards).
A device has a describing structure containing a 'name' and a 'description' string member. It's up to the application which one to display to the user.
Name is filled with the adapter name (the GPU's name in dgVoodoo) and description is filled with the monitor name (\\.\DISPLAY# strings) both coming from DXGI (from Windows internals).
Also, if you have multiple monitors, meaning multiple DX devices, some applications choose the last one from the enumeration, while others usually just use the first or the primary one. That's why you can select one adapter (+optionally a connected display) in the setup, to hide the others.

UCyborg wrote:

But there's no guarantee it will work flawlessly forever with original DLLs. The risks associated with doing heavy stuff in DllMain have been known forever, but Remedy guys haven't considered that, and few years later, things started to break. It still seems to work flawlessly on NVIDIA out of the box, at least on 368.81 drivers, but again, there is no guarantee this will always be the case.

In such cases, some people love to blame Windows, drivers etc. because it happened to work on early versions of those, only careful examination reveals the actual culprit.

Yes, exactly. I always wondered how can it be that Win32 documentation clearly states that calling Win32 from DllMain is a bad practice because of potential deadlock, and in spite of that, senior developers are willing to just ignore that.

Peixoto wrote:

Dege wrote:

D3D11 can only accept shader byte code of version 4.x/5.0, so old D3D8/9 shaders (1.x - 3.x) cannot be utilized without recompil […]
Show full quote

gameragodzilla wrote:

Why not use Komat's method then if it seems to function fine without the brief lagging?

D3D11 can only accept shader byte code of version 4.x/5.0, so old D3D8/9 shaders (1.x - 3.x) cannot be utilized without recompiling.

gameragodzilla wrote:

Though seems like Komat is only compatible with Pandora Tomorrow rather than Splinter Cell 1's buffer shadows so I guess there's a difference between the two games?

Fixing the shadow buffers (SC1) could be possible through pure D3D8 but the fix needs additional logic over MS D3D8 then.

If you don't mind, could you explain how it could be done? I wanted to try it, just for the fun of it

Well, all of Komat's fix are also needed. In fact, it should be added to Komat's fix.

If you can fix that 3DMark2001 SE issue it will be fun to test the D3D11 wrapping with "Nature" as an heavy-PS 1.x workload.

lowenz wrote:

If you can fix that 3DMark2001 SE issue it will be fun to test the D3D11 wrapping with "Nature" as an heavy-PS 1.x workload.

I hope it's just the question of adding support for (some of) texture formats Q8W8V8U8, V16U16, W11V11U10.

Max Payne 1 works well with the fix and dgVoodoo2+ReShade 3.0.6
Max Payne 2 works well with the fix and dgVoodoo2 BUT for a strange reason it can't load dxgi.dll of ReShade (and yes, the OSD monitor shows me that the rendering is done in D3D11).

Widescreen Fix works well, just use the lastest ASI Loader DLL (renamed "msacm32.dll") for Max Payne 1 and 2.1 version for Max Payne 2 (renamed "msacm32.dll").
https://github.com/ThirteenAG/Ultimate-ASI-Loader/releases

The proof 😁

Why is the screen in Jedi Knight always stretched to the whole screen (16:10) instead of 4:3?

Without dg the screen is correctly pillarboxed which is what I want.

In other words, why doesn't dg respect the setting in display drivers? I'd like to play in 1280x960 without any resolution magic or scaling on part of dgVoodoo (the driver and monitor would display this resolution correctly).
I can't use the scaling options in dg setup because then the mouse stops working in menus (as described earlier by someone in this thread).

Win10, HD5770.

PS. what I'm asking for is a "native resolution" mode: if the game asks for e.g. 640x480, then do exactly that, and let the drivers and hardware do the thing they are configured to - just like basically every game does without dgVoodoo.

Dege wrote:

Hmm... it's interesting. I should revise MP1&2 then.
I remembered that MP1 is DX8 but is of the initializing-from-DllMain type, while MP2 is DX9, so dgVoodoo is unusable for them.

Nope, pure DX8, just does who knows what with d3d9 before it fully launches, check the latter 2 screenshots: http://imgur.com/a/jMVZo
And here are the patches for both Max Payne games that make this possible: Max Payne 1 & 2 Startup Hang Patch

Dege wrote:

Well, in DX<=9, a device corresponds to a monitor. Even if you have 2 monitors attached to the same video card, they still appea […]
Show full quote

Well, in DX<=9, a device corresponds to a monitor. Even if you have 2 monitors attached to the same video card, they still appear as 2 separate devices in old DX. (XP DX9 had fullscreen-only support for dualhead videocards).
A device has a describing structure containing a 'name' and a 'description' string member. It's up to the application which one to display to the user.
Name is filled with the adapter name (the GPU's name in dgVoodoo) and description is filled with the monitor name (\\.\DISPLAY# strings) both coming from DXGI (from Windows internals).
Also, if you have multiple monitors, meaning multiple DX devices, some applications choose the last one from the enumeration, while others usually just use the first or the primary one. That's why you can select one adapter (+optionally a connected display) in the setup, to hide the others.

True. I've read with d3d8 you can use IDirect3D8::GetAdapterMonitor, then call GetMonitorInfo on returned handle to get the monitor number (\\.\DISPLAY#). Then I suppose you can present options in this style: GPU name @ monitor number.

Mafia, with regular d3d8.dll, while displaying adapters the same way Max Payne does, will actually start on second monitor if i choose so, while Max Payne presents 2 devices, but starts only on the primary one. What's more, config dialog always by default presents resolutions of my secondary, smaller monitor, so I have to click the other device to get right resolutions.

Good thing -nodialog parameter exists. I think the problem is that it internally operates with device description instead of its sequential number. You can see it stores it in registry with the rest of the settings. 3D Mark, however, with stock d3d8.dll, reports resolutions of my primary monitor only if I disable the secondary monitor.

lowenz wrote:

Widescreen Fix works well, just use the lastest ASI Loader DLL (renamed "msacm32.dll") for Max Payne 1 and 2.1 version for Max Payne 2 (renamed "msacm32.dll").

There is a bug in latest ASI loader with Direct3D8DisableMaximizedWindowedModeShim option, located in scripts/global.ini. If you turn it off, it works. The purpose of this option is to make stock d3d8.dll work properly by disabling forced maximized windowed mode, because geniuses at Microsoft want you to force stop playing "legacy" games by introducing options that break old games in strange ways.

This mode is there supposedly in the name of compatibility, but all I've seen it does (in addition to preventing games from running in true fullscreen mode) is preventing users from adjusting gamma in games and in some cases making them crash when anti-aliasing is enabled. Before Windows 10, it was enforced only for certain games, but on 10, it's enforced for anything D3D8.

Anyway, this option calls LoadLibrary with absolute path to system d3d8.dll before game wants to load it instead of just LoadLibrary("d3d8.dll"), which would pick a dgVoodoo one and since dgVoodoo doesn't export Direct3D8EnableMaximizedWindowedModeShim function, things would work properly regardless of whether user uses stock d3d8.dll or dgVoodoo's d3d8.dll. Will report the bug on GitHub.

Wow, thanks for the full explanation!

OK, tested. Setting Direct3D8EnableMaximizedWindowedModeShim=0 it works with the lastest ASI loader BUT ReShade can't be hooked yet.

The bug with ASI Loader I mentioned isn't the only one, there is this one as well: https://github.com/ThirteenAG/Ultimate-ASI-Loader/issues/3 Makes some games crash when its DLL is named d3d8.dll.

As for ReShade issue, I'm pretty sure it's connected to whatever weirdness Max Payne 2 does on startup. If you look at loaded module list with Process Hacker, you can even see D3D12.dll on the list. This is without extra DLLs in game folder. Not only does it do some D3D9 calls on startup, it does something that causes Direct3D 12 runtime to be loaded on Windows 10.

dxgi.dll is loaded as well. Could be that it does some calls that cause those DLLs to be loaded by COM infrastructure. AFAIK, if DLL is loaded via COM, it takes something more than just a proxy DLL in game folder to override it.

What? It calls the D3D12 runtime? 😐 Without the ASI loader? How can it be?! (It's from 2003!)

🤣, with "dsound.dll" ReShade hooks correctly but obviously the game crashes after the sound initialization :p

Here, try my patched MaxPayne2.exe, it will solve ReShade not working and game will start faster! 😁 What it does? I NOPed out the function call at the offset 0xF0DF, which indeed does create some object with CoCreateInstance, which causes D3D12.dll to be loaded along with bunch of other libraries, preventing ReShade's dxgi.dll from working. Even though I'm not a fan of those patches that skip some code, this is apparently one of those cases where the code in question apparently doesn't do anything required for the game to operate properly. At least I haven't noticed any side effects.

As for dsound.dll trick, I think it would have to act as dsound.dll proxy for it to work. Besides, you need Creative ALchemy's dsound.dll to get EAX effects. And Creative ALchemy does something special the first time you start it, just dropping its dll in game's folder wouldn't work as desired neither (no 3D sound and EAX).

UCyborg wrote:

Here, try my patched MaxPayne2.exe, it will solve ReShade not working and game will start faster! 😁 What it does? I NOPed out the function call at the offset 0xF0DF, which indeed does create some object with CoCreateInstance, which causes D3D12.dll to be loaded along with bunch of other libraries, preventing ReShade's dxgi.dll from working. Even though I'm not a fan of those patches that skip some code, this is apparently one of those cases where the code in question apparently doesn't do anything required for the game to operate properly. At least I haven't noticed any side effects.

It works with ReShade but ASI loader can't hook with msacm32.dll 😒

UCyborg wrote:

As for dsound.dll trick, I think it would have to act as dsound.dll proxy for it to work.

Of course, but now it's sure that the problem relies in MaxPayne2.exe and not in dgVoodoo2 :p

VirtuaIceMan wrote:

Here's a large collection of older PC racing game screenshots I took, upscaled using a mix of dgVoodoo and nGlide: http://forum.arcadecontrols.com/index.php/top … c,152678.0.html

How'd you get it working with Daytona USA Deluxe?

lowenz wrote:

It works with ReShade but ASI loader can't hook with msacm32.dll 😒

winmmbase.dll got all the hooking (ASI Loader + dgVoodoo2 + ReShade) working 😁

Now I can have a good 2017 😁

lowenz wrote:

Of course, but now it's sure that the problem relies in MaxPayne2.exe and not in dgVoodoo2 :p

I think what that function does is get some diagnostic info from DxDiag and print it in log file, which I still don't know how to get the game to create on regular basis. It seems the only things that aren't logged with that function disabled are GPU and sound card vendor and device IDs, but who needs that for playing. Sound like something that belongs in debug version of .exe, especially since it slows down the startup process.

Glad ReShade now works for you as well! 😁