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.
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? 😁
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.
- 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):
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;
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:
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:
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 ?
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)
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
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 😁
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
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.
Last edited by De-M-oN on 2016-04-28, 20:43. Edited 1 time in total.