Yes, the save game i posted contain the positions where Komat dll has issues also.
So in a conclusion, is there something you can do about it? Some general options to choose from that can be applied to other games also, that can fix issue like this?
I dont think SC PT will be the only game out there with this kind of problem.

I'll test Dege vs Komat (same spot) with:

*Radeon 7850 - Win 7
*GeForce 9600M - Win 10
*GeForce 750 Ti - Win 10

About the first here's the result:

Dege (D3D11):

Komat (D3D8):

The colour output is the same for light shafts.....but I see strange behaviour with the anisotropic filter / mipmap (AF 16x forced via driver panel)
Take a look to the SECOND window on the right!!!! Or the terrain below!!!!

Is the (driver-forced) AF *NOT* applied with Dege wrapper (D3D11)?
WTF? 😁

lowenz wrote:

I'll test Dege vs Komat (same spot) with: […]
Show full quote

I'll test Dege vs Komat (same spot) with:

*Radeon 7850 - Win 7
*GeForce 9600M - Win 10
*GeForce 750 Ti - Win 10

About the first here's the result:

Dege (D3D11):

Komat (D3D8):

The colour output is the same for light shafts.....but I see strange behaviour with the anisotropic filter / mipmap (AF 16x forced via driver panel)
Take a look to the SECOND window on the right!!!! Or the terrain below!!!!

Is the (driver-forced) AF *NOT* applied with Dege wrapper (D3D11)?
WTF? 😁

I think Geforce 4 Ti could not do 16x AF. Only 8. Maybe this is the cause.

I don't use GPU preset with SCPT, I use generic device with 1024 MB RAM.....but AF must apply.

The XOR image confirms the absence of AF:

Yes, there's something not working with forced AF16x + dgVoodoo2 (move the cursor and see the terrain)

http://screenshotcomparison.com/comparison/170378

Dege wrote:

- MCM2: I'd try it myself, however I either cannot install my copy, even on a virtual pc with XP, or can't start the game itself because it always quits with some making-no-sense error message, can't remember which one, but didn't find any patch for that,

Thank you for testing anyway. I can load mcm2 with K-Lite_Codec_Pack (or original CD in) and d3drm.dll. But the game could always only get into the first "blue room". When I was trying to play, it was crashing.

With your simulated GPU I can play offline already at least. Probably mcm2 tries to load more files for online playing, like internetexplorer(-files). I can't understand it yet, but I would be very happy about new ideas. 😊

Any chance you will add shader support? I'd love to see some old directdraw games enhanced! From my shader (may look slightly distorted if not viewed fullscreen in 1680x1050):

You can already use ReShade on top of dgVoodoo2.

Hello all.
I am trying to use the dgVoodoo v2.51 for playing Arabian Nights released by Wanadoo/Visiware
in 2001 or 2002 that is one of the Prince of Persia series followed by Prince of Persia 3D.

My PC has;
CPU: Intel Core i5 RAM 6GB Running Windows 10 64bit
NVIDIA Geforce GT330M GPU Video Memory 512MB
Chipset PM55 Express
NVIDIA Driver version 9.18.13.4195 (29 Jan. 2016)

Direct3D wrapping for the game , dgVoodoo worked fine.
But I got a problem in the wrapper for 3Dfx.
The game launched in 3Dfx mode and game menu was OK.
But when I clicked its submenu such as New Game or Credit, game stopped
suddenly.
Game exe is _st_3dfx.exe set "NO COMPATIBLITY" for lauching the game.

Error massage in the file "_error.txt" generated by the game is;

wininit ok
3DFX glide init
########## setvideo=2
>>>Free texture memory=4194304
setpalette
=======================================================================
EXCEPTION_ACCESS_VIOLATION (C0000005) in IP=0x442FF1
TIME:131
EAX=00000000 EBX=00000000 ECX=CAC7FD88 EDX=00000000
ESI=00465D83 EDI=0019F63F EBP=0019F84C ESP=0019F218
Bytes at IP : 89 39 83 C1 04 4A 75 F3 8B 54 24 10 03 F3 03 CD
Stack content:
00461AF8 00000000 0019FEE0 00001000 6DDD5851 6E02B380 CB0003C8 0BD0AEF8
6DDD5864 00000070 0019F240 0019F240 15000015 775B6B50 FFFFFFFE 00A38372

ENTITY TYPE: main
=======================================================================
UNactiveapp
REactiveapp=1

dgVoodoo setting ;

If you have any clue to work dgVooboo 3Dfx wrapper fine for the game Arabian Nights in Windows 10 64bit+DirectX 11 I would very appreciate it.
Thank you in advance.

Dege wrote:

Because, - For Glide, one choose an adapter (and a connected output) on which the rendering goes - For DirectX, one choose which […]
Show full quote

lowenz wrote:

A question: why "All of them" entry is named in that way (only in D3D12 multiple/different GPUs can work together, if I'm not wrong)?

How about change "All of them" to a "Default" adapter (maybe the one actually used by Windows Desktop) so you can bind it to WARP (and grey out the field while WARP is selected as Output API).

Because,
- For Glide, one choose an adapter (and a connected output) on which the rendering goes
- For DirectX, one choose which adapters to enable for taking part of the DDraw/D3D8 device enumeration

Even old DX can drive multiple GPUs. D3D9Ex and above supports limited video memory sharing between GPUs, even the Desktop Window Manager needs this feature when drawing the desktop in Aero Mode (for multimonitor systems).
What DX12 adds to all of this, is "just" efficient, page-level videomemory sharing through mapping, between GPUs, so the needless copying from one to another, or reusing a texture without copy but with slow reaching because of system bus speed, are avoided.

I added 'Microsoft Basic Render Driver' as an adapter for WARP api output, with 'default' display output.

-------------

Ok, now Pandora Tomorrow:

Here is a debug-screenshot of light polygons drawn with alpha blending and depth-testing disabled.
Clearly there are a yellow zone (RGB: 21,21,19), a red zone (RGB: 21, 19, 19) and a white zone (RGB: 19, 19, 19).

The game simply puts out color coming from the vertex shader (multiplied by a shadow map, so that even the light can be in shadow 😁), so
it's simple like hell. The vertex shader used for the light polygons is:

Copy code to clipboard

1Direct3DDeviceImpl8::CreateVertexShader
2Vertex Shader Validator
3
4     vs.1.0
5
6     mov   r0,  v0
7     max   r0.x,  v0.xxxx, c0.xxxx
8     mul   r0.x,  r0.xxxx, c86.xxxx
9     add   r0.x,  r0.xxxx, c86.wwww
10     mul   r0.z,  r0.zzzz, c86.zzzz
11     mul   r0.y,  r0.yyyy, c86.yyyy
12     mul   r0.y,  r0.yyyy, r0.xxxx
13     mul   r0.z,  r0.zzzz, r0.xxxx
14     mov   r0.w,  c1
15     m4x4   oPos,  r0, c2
16     m4x4   r1,  r0, c18
17     mov   oT0,  r1
18     mov   oT0.z,  c1
19     dp4   oT2.x,  r0, c22
20     dp4   oT2.y,  r0, c23
21     dp4   oT2.z,  r0, c24
22     dp4   oT2.w,  r0, c25
23     
24     mov   r1,  c87            <----- this part is calculating the color
25     mov   r2,  v0.xxxx
26     add   r2,  c1, -r2
27     mul   r3,  r2, r1
28     mov   oD0,  r3            <----- color output is in r3
29     mov   oD1,  r3
30
31Vertex declaration:
32
33     stream:0, v0: FLOAT3
34     stream:0, v1: FLOAT3
35     stream:0, v3: FLOAT2
36
37Generated VS 4.0:

It shows that the game calculates the light vertex color based on its incoming position-like data (it explains why the glitch can be viewpoint-dependent) and then multiply it by a single constant (c87). From the debug log, c87 is set to:

Copy code to clipboard

1Direct3DDeviceImpl8::SetVertexShaderConstant
2   c[87] = (0.003922, 0.003081, 0.001892, 1.000000)

So that, red is the most dominant color (it's factor is 0.003922). It seems the game tries to compensate sg coming from the position to get white color, but it doesn't work very accurately for all cases. The difference between the calculated red, green, blue components is minimal (max 1/256) but if they are drawn in multiple times, and alphablended onto each other (additive blending is used) then the error accumulates, like in this case, and causes that color-glitch (21-19 is 2/256). For 16 bit rendering, with dithering enabled, this is much less visible, if visible at all, at the expense of color banding.

So, it's the game, it's not a bug.

Out of pure curiosity, how are you dealing with the D3D8 shaders ? You compile them with legacy flags or parse and translate them to SM 4 ?

daniel_u wrote:

Yes, the save game i posted contain the positions where Komat dll has issues also.
So in a conclusion, is there something you can do about it? Some general options to choose from that can be applied to other games also, that can fix issue like this?
I dont think SC PT will be the only game out there with this kind of problem.

Unfortunately, there isn't... 🙁
Struggling for lower floating point precision in vertex shaders may help but I don't want to play with it, there are a lot of other issues to solve.

lowenz wrote:

Yes, there's something not working with forced AF16x + dgVoodoo2 (move the cursor and see the terrain)

http://screenshotcomparison.com/comparison/170378

Is it a DX11 limitation, or dgVoodoo again? 😀

lowenz wrote:

You can already use ReShade on top of dgVoodoo2.

Yes, I concur. I don't know Reshade very well but I'm curious if there is something that needs support from dgVoodoo side, for achieving custom shading.

Peixoto wrote:

Out of pure curiosity, how are you dealing with the D3D8 shaders ? You compile them with legacy flags or parse and translate them to SM 4 ?

No, I can't translate them with legacy flags or sg. All I get is raw D3D8 shader bytecode, so I have to parse and validate it myself. After that, a HLSL source is genereted from that, which is compiled to SM 4.0. For pixel shaders, only a HLSL template can be generated which gets its concrete forms -and compiles- later, depending on the current pixel pipeline state.

-----

I think I'm going to open mini TestTrack for myself, for the reported bugs and issues. 😀
So far I've kept them in my mind, but there is too many now. NFS4, Arabian nights and others, I should try them myself to see what's going there.

@Teleguy: I think I'm going to whip up a logging debug version of Glide or D3D8 to see what point it fails at the initialization for you, at 10.0.

Edit: I intended the WARP renderer to be a kind of "reference" driver, but unfortunately it doesn't seem to be perfect:
- It has no output so gamma control doesn't work with it
- Only black screen for Glide when in fullscreen... (when in windowed, it's ok) 😕
- Definitiely there are rendering errors with some scene demos I tested with

Yes, WARP *classic* fullscreen handling is strange. Borderless fullscreen all the way?

Dege wrote:

http://screenshotcomparison.com/comparison/170378
Is it a DX11 limitation, or dgVoodoo again? 😀

?

Is it related to a depth buffer mumbo-jumbo again? 😁

Dege wrote:

I think I'm going to open mini TestTrack for myself, for the reported bugs and issues. 😀
So far I've kept them in my mind, but there is too many now. NFS4, Arabian nights and others, I should try them myself to see what's going there.

Thank you for replying that you will keep "Arabian Nights" in your mind.
I hope dgVoodoo will work on "Arabian Night" for 3Dfx mode as well as now working in Direct3D mode.

Tested dgVoodoo2 D3D with my i3 530 integrated GPU (HD Graphics - 1st core generation - 2013 drivers) with existing Radeon 7850 profiles (all working with the Radeon+Catalyst 16.x)
Crash at start for all 😁

But hey, 2013 drivers.....

lowenz wrote:

Yes, WARP *classic* fullscreen handling is strange. Borderless fullscreen all the way?

It doesn't seem to be because my desktop moves away a bit on the secondary monitor when I use low resolutions like 800x600 or sg.
Perhaps it's mapped to legacy GDI display functions.

lowenz wrote:

?

Is it related to a depth buffer mumbo-jumbo again?

It don't think so. At least, it shouldn't.

RaymanForever2007 wrote:

Thank you for replying that you will keep "Arabian Nights" in your mind.
I hope dgVoodoo will work on "Arabian Night" for 3Dfx mode as well as now working in Direct3D mode.

Ok, I fixed the problem. Now it runs through Glide too.

lowenz wrote:

Tested dgVoodoo2 D3D with my i3 530 integrated GPU (HD Graphics - 1st core generation - 2013 drivers) with existing Radeon 7850 […]
Show full quote

Tested dgVoodoo2 D3D with my i3 530 integrated GPU (HD Graphics - 1st core generation - 2013 drivers) with existing Radeon 7850 profiles (all working with the Radeon+Catalyst 16.x)
Crash at start for all 😁

But hey, 2013 drivers.....

I'm in the opposite situation. It works on my Core i7 with drivers from 2011. Newer ones are crap. 😀

----

A question: how should I set the API output (thrash driver) in NFS4?
By default it starts with the DDraw renderer. Should I launch it with a switch like "-3dfx" or sg like that?

You need a modified 3D Setup to be able to choose Glide there.
Just use a fresh installed NFS4 and install the expansion pack. It contains everything you need to run the game plus a lot of extra cars and tracks.
http://www.iplounge.net/forum/viewtopic.php?t=1756

De-M-oN wrote:

You need a modified 3D Setup to be able to choose Glide there.
Just use a fresh installed NFS4 and install the expansion pack. It contains everything you need to run the game plus a lot of extra cars and tracks.
http://www.iplounge.net/forum/viewtopic.php?t=1756

Thanks!
I tried some tracks with weather on, and I got stable 60fps all the time (at 1280x1024, 4xMSAA), through Glide and DX7 High Poly renderers.
What if you try with DX7? Do you experience the phenomenon?
It's strange because the rendering method of this game doesn't explain this all, there are no dynamic buffer locks and such, that are typically fps choppers.

Maybe the 16bit depth buffer was the problem. I thought it was needed to avoid the z-texture fighting with headlights on nightraces, but apparently not. A very quick look into a lost canyon nightrace with weather had surprisingly still not the problem

I really wonder, because you mentioned in readme that it is exactly for doing that job. But you said it for NFS 3 though. But I assumed it is for NFS 4 the same due to same engine.
The 16bit depth buffer introduced other artefacts on NFS 4 though - like texture fighting on traffic signs and some cliffs look through the street.

But without the option it seems to work now and also the fps stayed this time on 60.

edit: The obversation was too short.

A race on lost canyon with 7 opponents (full field), this time on day, not night, and weather enabled, the water spray of the tires of the opponents still caused fps dropping down to 30 🙁

I use 2560x1600 as resolution and 8x MSAA. But without MSAA the situation doesnt get better. And reducing the resolution is no option for me and other glide wrapper manage to handle the fps. But for some reason nGlide gives me at NFS 4 now a AMF error and zeckensack has good fps too, but it has this headlight z-texture fighting problem on the nightraces.

My hope is your wrapper 😀

edit 2: I'm this time totally confused, because I tried again MSAA at off and now full 60fps all the way.

I dont get it. I swear it didnt helped last time. I could only imagine that I had AA in graphics driver enabled for accident.

But I'm also curios that it takes so much performance on a GTX 680 using MSAA 8x on NFS 4.

I could imagine that it is because it anti aliases every single particle of the water spray? 😁

Because its interesting that the fps only drops if you're close to this waterspray, or other effects like this.