Tech demos - general discussion

[CoolGamer]

I am not able to override anti-aliasing via Nvidia control panel either. I first noticed this when I was running the scene demo Kasparov by elitegroup via dgVoodoo. MSAA via dgVoodoo worked, but overriding and/or enhancing it via Nvidia control panel did not work. Different levels of MSAA is very noticeable in the scene where the 4 legged robot walks.
http://www.pouet.net/prod.php?which=374

I wonder if there are cases where forcing anisotropic filtering via Nvidia control panel does not work. It is not always easy to notice these things by looking. That's why having 16x anisotropic filtering built into the dgVoodoo control panel would be convenient, ensure proper operation, and be cool


Please take a look at the MadOnion (Futuremark) DX7 Benchmark Demo named XL-R8R when you have time. UCyborg analyzed it and confirmed that its not a DLL Main issue. There is a compatibility problem when we run it via dgVoodoo. The demo works fine natively. I quoted UCyborg's post from the DLL Main thread below.
https://www.futuremark.com/benchmarks/legacy

Never mind, it's not DllMain. It tries to query user mode driver DLL info, which doesn't work through dgVoodoo, so it throws exception and quits. It calls GetFileVersionInfoEx on non-existent file named dgVoodoo, which fails. Natively, the file would be nvd3dum.dll on NVIDIA hardware.

Thanks UCyborg!!

[UCyborg]

Here are some differences from Mafia's log.txt that might be relevant.

dgVoodoo (selected ATI Radeon 8500):

Code: Select all

Date: 04/10/17    time:18:57:04
LS3D Engine V3.95.1         Jun 24 2003    GetVer:395


Detected OS: Windows ?? ver. 6.2.9200
Detected CPU: AuthenticAMD,  2999MHz, family:15, model:4, stepping:2
This DLL uses standard x87 math
Current display mode: 1920x1080, 59Hz, format: D3DFMT_X8R8G8B8

Using adapter number: 0
              Driver: NVIDIA GeForce GTX 750 Ti
         Description: \\.\DISPLAY1
      Driver version: 17479.02.53.0000
           Vendor ID: 1002
           Device ID: 514E
           SubSys ID: 0
            Revision: 0
                GUID: CE10A3AA-1935-4C5A-A2819D0C02AB6AA1

Using HARDWARE T&L.
Using SINGLEPASS rendering.
Trying to create device with FULLSCREEN mode: 1920x1080, 0Hz, BackFormat: D3DFMT_X8R8G8B8, DepthFormat: D3DFMT_D24X8

Maximum available texture memory ( AGP + VRAM ): 232 MB

Using texture formats:
   16bit textures: D3DFMT_R5G6B5
   1bit Alpha textures: D3DFMT_A1R5G5B5
   Alpha textures: D3DFMT_A4R4G4B4
   TrueColor textures: D3DFMT_A8R8G8B8
   DXT1 textures: D3DFMT_DXT1
   DXT3 textures: D3DFMT_DXT3


*** Sound management: 120 free 3D channels claimed.
*** FULL EAX 3.0 available ***
*** Speaker configuration: 5.1 SURROUND SOUND SPEAKERS


Native:

Code: Select all

Date: 04/10/17    time:18:59:18
LS3D Engine V3.95.1         Jun 24 2003    GetVer:395


Detected OS: Windows ?? ver. 6.2.9200
Detected CPU: AuthenticAMD,  2998MHz, family:15, model:4, stepping:2
This DLL uses standard x87 math
Current display mode: 1920x1080, 59Hz, format: D3DFMT_X8R8G8B8

Using adapter number: 0
              Driver: nvd3dum.dll
         Description: NVIDIA GeForce GTX 750 Ti
      Driver version: 10.18.13.6881
           Vendor ID: 10DE
           Device ID: 1380
           SubSys ID: 362D1458
            Revision: A2
                GUID: D7B71E3E-50C0-11CF-096D20161FC2C735

Using HARDWARE T&L.
Using SINGLEPASS rendering.
Trying to create device with FULLSCREEN mode: 1920x1080, 0Hz, BackFormat: D3DFMT_X8R8G8B8, DepthFormat: D3DFMT_D24X8

Maximum available texture memory ( AGP + VRAM ): 3997 MB

Using texture formats:
   16bit textures: D3DFMT_R5G6B5
   1bit Alpha textures: D3DFMT_A1R5G5B5
   Alpha textures: D3DFMT_A4R4G4B4
   TrueColor textures: D3DFMT_A8R8G8B8
   DXT1 textures: D3DFMT_DXT1
   DXT3 textures: D3DFMT_DXT3


*** Sound management: 120 free 3D channels claimed.
*** FULL EAX 3.0 available ***
*** Speaker configuration: 5.1 SURROUND SOUND SPEAKERS


I wonder why running natively reports that much memory. I've seen similar number in Advanced settings under Control Panel -> Appearance and Personalization -> Display -> Screen Resolution. 2 GB of dedicated graphics memory plus additional 2 GB of shared system memory.

[Dege]

It seems like there are still some issues with the Fog City demo (DX6) via WIP33. I listed them below:

1) Revolving logo in the beginning (the one that is overlaid on desktop) works with WIP33, but the word "MT" Logo (that is over the marble base) flickers/disappears and black bars flicker. When you run the demo natively there is no flickering.
2) When you click options, you will see that Anti-aliasing settings are greyed out. Anti-aliasing settings do work when you run the demo natively.
3) Please see the attached zip file with screenshots. Colors and lighting of some of the buildings and the exit logo do not look right.

Tirtanium demo DX6 also have lighting glitches (see attached screenshots).

I reverse engineered old software-only lighting codes part of DX1-6 and indeed, dgVoodoo wasn't fully compatible with that. Until now, because I changed the code and implemented it.
However, the flashing revolving logo at the beginning looks to be normal. I get exactly the same natively and also, debugging that part didn't unveil any bug at dgVoodoo side. Must be some bug on the demo side.
BTW, I also fixed some other bugs that affected some D3DRM applications. Now the D3DRM DX6 examples work fine (except a glitch, when moving their window because D3DRM updates the window partially and dgVoodoo cannot emulate the window-content moving like the windowing system does) and a demo using D3DRM now runs perfectly.

Please take a look at the MadOnion (Futuremark) DX7 Benchmark Demo named XL-R8R when you have time. UCyborg analyzed it and confirmed that its not a DLL Main issue. There is a compatibility problem when we run it via dgVoodoo. The demo works fine natively. I quoted UCyborg's post from the DLL Main thread below.
https://www.futuremark.com/benchmarks/legacy

UCyborg wrote:
Never mind, it's not DllMain. It tries to query user mode driver DLL info, which doesn't work through dgVoodoo, so it throws exception and quits. It calls GetFileVersionInfoEx on non-existent file named dgVoodoo, which fails. Natively, the file would be nvd3dum.dll on NVIDIA hardware.


Thanks UCyborg!!

Yes, that demo queries the driver dll name through DDraw and tries to acquire its version. Since dgVoodoo doesn't have a real driver dll, it fails and the demo throws and exception.
I don't know why the driver dll version is so interesting (for feedbacking it to the user?), maybe cutting out that code entirely would help.

[Dege]

I wonder if there are cases where forcing anisotropic filtering via Nvidia control panel does not work. It is not always easy to notice these things by looking. That's why having 16x anisotropic filtering built into the dgVoodoo control panel would be convenient, ensure proper operation, and be cool

dgVoodoo has 4 checkboxes for controlling texture filtering. To introduce anisotropic filtering modes, those should completely be changed to a single drop-down list, containing a lot of filtering options.

[UCyborg]

Here's the XL-R8R executable that doesn't query graphics card information. It was easier than figuring out how to bypass just the DLL version info part. So the information will be missing on that profile page after the demo, there are a lot of other missing things there anyway. And apparently there is no DXGI API for getting under the hood driver DLL name, the closest thing is IDXGIAdapter::GetDesc method, which gives graphics card's name, vendor and device IDs and amount of memory among the things one might care about.

[CoolGamer]

UCyborg, thanks for the patch. I tried it but I could not get dgVoodoo WIP33 to run XL-R8R by using your patched exe. I was able to run your patched XL-R8R exe natively on my Windows 7 OS. Maybe there are still some graphics card info related queries left in the patched exe that make it crash with dgVoodoo.

[Dege]

Thanks UCyborg, I always wonder how quickly you patch problematic stuffs!

Interestingly however, the demo with the patched executable starts for me on a machine with an AMD card but not on another with an nVidia one (with dgVoodoo).
I did some additional patching, this one works for me.

[UCyborg]

Dege, it seems it's connected to whatever the heck that loop above that code you patched does. It has 2 exit points, one skips that part. Ironically, the issue didn't show up on my NVIDIA.

Ah yes, the patches that just skip random bits of code! While not the ideal course of action, it is perfectly valid sometimes. Drakan used to have a bug where connecting to game servers overwrote variable that holds IP address to bind the socket to when hosting your own server, so if you tried starting the server after playing somewhere else, it tried to bind the socket to that server's IP address.

Max Payne 2 also does some queries before it starts, but that information isn't even presented anywhere, certainly not under usual circumstances. And skipping that whole function speeds up startup time, probably because a bunch of different DirectX runtimes are loaded as result. XL-R8R is a bit trickier, because it checks whether the information is valid. And it seems there's not just one point where it can nope out. The part I patched with unconditional jump otherwise gives message that it couldn't find 3D acceleration. That part where I skip that big function, there also used to be a call to the function that doesn't do anything at all.

CoolGamer, hopefully, Dege's executable will work on your end.

One thing I've noticed now that I have Windows 8.1 on my main PC, 3D Mark 2000 and 2001 weren't complaining about not having enough memory on Windows 10, now they do unless I add GlobalMemoryStatus2GB shim with Compatibility Administrator. Maybe I just have more free RAM now or something. Why these checks fail so commonly anyway, are the values being casted as signed integers so they wrap around beyond 2 GB?

If we figured out that problematic Matrox demo, that'd be great!

[CoolGamer]

Actually Dege's patched XL-R8R executable does not start at all on my machine with or without dgVoodoo. No error messages, it just terminates itself. It might be related to the Nvidia drivers on the system. I have nvidia driver version 342.01, which is the latest possible driver Nvidia released for my legacy GT 230m gpu.

I also agree that it would be great to get the problematic Matrox G200 tech demo working via dgVoodoo.

[UCyborg]

So we need to figure out a better patch! Or maybe dgVoodoo could just return its own ddraw.dll? Can't be any worse than it is now, can it? I have to try patched executable on Wine, original throws exception there as well.

[dr.zeissler]

...I also agree that it would be great to get the problematic Matrox G200 tech demo working via dgVoodoo.

The Screensaver?

[Dege]

So we need to figure out a better patch! Or maybe dgVoodoo could just return its own ddraw.dll? Can't be any worse than it is now, can it? I have to try patched executable on Wine, original throws exception there as well.

I tried that, but it didn't make the trick either.

[UCyborg]

Here's another shot at this. Here's the .exe with the following modifications:

• Push the name of ddraw.dll as the argument to the function that gets the file version info
• Replace string Direct3D HAL with dgVoodoo HAL
• Replace string Direct3D T&L HAL with dgVoodoo TnL HAL

Will only work with dgVoodoo. Perhaps changing those strings in dgVoodoo would help it run without modifying it?

[dr.zeissler]

ähm sorry for interrupting, patching xl-r8r to work with dx61 would be nice

[UCyborg]

What kind of issue do you have on your end? XL-R8R works on 2 of my own machines natively (original executable).

Matrox G200 demo we were discussing has severe problem related to usage of DllMain in its Matrox.vd DLL file, the kind we haven't encountered before.

[CoolGamer]

UCyborg, thanks for the updated patch for XL-R8R. It seems like I don't have any luck with these on my machine . This one did not work via dgVoodoo either.