Sorry, indeed, I forgot the "temp" subdir from the link. I edited and corrected it in my prev post. Also, reuploaded the zip, it was just a quick-work version, I was in a big hurry.

VEG wrote:

I've added an ability to use large textures 512×512, 1024×1024 and 2048×2048 in the NFS3 Modern Patch. It would be nice to have an ability to choose more Onboard RAM, e.g. 32MiB, 64MiB, or even 128MiB.

Are they for 2D-tiling purposes or is there a possibility to change the game textures to higher resolution ones?

Dege, it is possible to use such big textures for cars and track elements.

VEG wrote:

Dege, it is possible to use big textures for cars and track elements.

Great! Then I''m going to add new values to the 'onboard ram' combo box.

Dege wrote:

VEG wrote:

Dege, it is possible to use big textures for cars and track elements.

Great! Then I''m going to add new values to the 'onboard ram' combo box.

About the RAM values, can you make sure that selecting the GeForce Ti 4800 or the Radeon 8500 presets, the values are automatically set to 128? 'cause actually if you selected 1024 or 512 MB for the generic GPU AND you switch to the 4800/8500 those bad values ramain.

I couldn't reproduce the texture corruption myself, but, found a very basic bug around the scaling that, according to the symptoms, can smoothly cause it. 😊
Does this fix solve the problem for you?

Yup. Fixed. The problems i've seen in 640x480 are not there anymore.

Is it possible to this texture edge fringing that punch though?
PSOBB, on a private server, has this on some areas, such as the legs on this monster. http://i.imgur.com/KiiCgwZ.png
Also Grand Theft Auto III, Vice City, and San Andreas has this issue especially on trees and foliage and some fences.

I get mip-map corruption in PSOBB too, I disable mip-maping to avoid the issue when playing. http://i.imgur.com/ulTir9C.png

Diablo 2 problems are now solved by Blizzard itself, with 1.14a patch 😁

lowenz wrote:

Diablo 2 problems are now solved by Blizzard itself, with 1.14a patch 😁

Ha! Didn't think that would happen!

I compiled the 2.51 pack, made changes to dgVoodooSetup.

If this works with VEG's NFS3 patch with high-res textures then I release it. 😁

http://dege.fw.hu/dgVoodoo2_51.zip

lowenz wrote:

Diablo 2 problems are now solved by Blizzard itself, with 1.14a patch 😁

Yes, I heard about that. But if the wrapper doesn't work with the old one then it means it has bugs to be fixed. 😀 (fixed)

Truth Unknown wrote:

Is it possible to this texture edge fringing that punch though? PSOBB, on a private server, has this on some areas, such as the […]
Show full quote

Is it possible to this texture edge fringing that punch though?
PSOBB, on a private server, has this on some areas, such as the legs on this monster. http://i.imgur.com/KiiCgwZ.png
Also Grand Theft Auto III, Vice City, and San Andreas has this issue especially on trees and foliage and some fences.

I get mip-map corruption in PSOBB too, I disable mip-maping to avoid the issue when playing. http://i.imgur.com/ulTir9C.png

It looks like alpha-testing transparency. Anyway, I will check it natively.

BTW, there are games, like Splinter Cell, that change the window size after they switched to fullscreen. In response, DXGI pushes back the rendering into windowed mode. It's an issue to be resolved later, I play those games by enabling manual Alt-Enter-modeswitching and force them back to fullscreen if needed.

Dege wrote:

If this works with VEG's NFS3 patch with high-res textures then I release it. 😁

It seems that it works, thanks 😀

Got a problem with another game. This time it's Druuna: Morbus Gravis, which is a rubbish but IMO interesting game. It's not a big deal as the game works natively with the force simple window app compatibility fix, but it doesn't work with dgVoodoo so I thought I'd let you know. AFAIK the game is using DirectX 6 or 7, not 8.

It's supposed to look like this:

It actually looks like this:

Sometimes bits of the model become solid as the character moves around.

It seems that DX8 wrapper doesn't look for dgvoodoo.conf in the own directory, like glide3x.dll does. Can it be fixed?

Also I've tested dx8 wrapper and it seems that it works a little bit buggy on some places of the track. Some huge parts of tracks are blinking during moving (and only during moving, it is not easy to catch it for the screenshot). For example, try to race the Redrock Ridge, and you will see this bug. It is hard to overlook it if it can be reproduced on your system. My GPU is Intel HD 4600.

I'm thinking about adding your DX wrappers also to my patch, as dgdx8 and dgdx6 renderers. It seems that performance of this DX wrapper is good even on my system. That's a pity that performance of dgVoodoo's glide3x.dll is poor on the integrated GPU 🙁

ddraw.dll wrapper works fine. With the dx6 renderer it works fast (much faster that without your wrapper for some reason) and reads settings from the dgvoodoo.conf from the own directory. But for some case it can't be restored after minimizing. Original game with the dx6 renderer can be restored after minimizing, but all textures will be broken. It looks like this, but it is still playable 😀

Probably, it is possible to revert possibility at least to restore game window with DX6 and dgVoodoo's ddraw.dll.

Probably, it is important: NFS3 uses different threads for the window message loop and for the rendering. NFS4 does same thing.

Hi Dege, I will test new release 2.51 with Resident Evil as soon as I am able (a few days I think). Do you think videos should now work properly in full screen?

Silanda wrote:

Got a problem with another game. This time it's Druuna: Morbus Gravis, which is a rubbish but IMO interesting game. It's not a big deal as the game works natively with the force simple window app compatibility fix, but it doesn't work with dgVoodoo so I thought I'd let you know. AFAIK the game is using DirectX 6 or 7, not 8.

Sometimes bits of the model become solid as the character moves around.

Maybe some z-buffer problem... I'll check that.

VEG wrote:

For example, try to race the Redrock Ridge, and you will see this bug. It is hard to overlook it if it can be reproduced on your system. My GPU is Intel HD 4600.

I guess it doesn't come with native DX8.

VEG wrote:

I'm thinking about adding your DX wrappers also to my patch, as dgdx8 and dgdx6 renderers. It seems that performance of this DX wrapper is good even on my system. That's a pity that performance of dgVoodoo's glide3x.dll is poor on the integrated GPU

Yes, Glide has a bit more complicated shaders because of texturing...

VEG wrote:

ddraw.dll wrapper works fine. With the dx6 renderer it works fast (much faster that without your wrapper for some reason) and reads settings from the dgvoodoo.conf from the own directory. But for some case it can't be restored after minimizing. Original game with the dx6 renderer can be restored after minimizing, but all textures will be broken. It looks like this, but it is still playable

How can I Alt-Tab out from the game? I downloaded the latest version of your patch and I couldn't do that with the DX renderer.
Do you have a work-version? 😀

VEG wrote:

Probably, it is important: NFS3 uses different threads for the window message loop and for the rendering. NFS4 does same thing.

Shouldn't be a problem.
BTW, aren't you going to fix the fog in DX8 (and maybe DX5) drivers? 😀
DX8 thrash driver probably drives DX in the same way as DX6, I hardly beleive it uses shaders, or even vertex buffers, or sg.
So the fix should be the same as for DX6.

LoneKiller wrote:

Hi Dege, I will test new release 2.51 with Resident Evil as soon as I am able (a few days I think). Do you think videos should now work properly in full screen?

No, I think will still get blank screen.
I'm planning to build-in some GDI support in the next version.

I have still to find a wrapper that correctly supports it, they all failed, the game is Tonko 4. 😉

Dege wrote:

I guess it doesn't come with native DX8.

Native DirectX 8 renders this track without any problems on my PC. I've tested your DX8 wrapper again and now it looks even worse: sometimes all polygons are distorted and flickering. Last time it was just a few polygons at some places of the track. I don't know what is the cause of this. I've recorded this video as an example: https://drive.google.com/file/d/0BxsYG4LzThr4 … iew?usp=sharing. Sometimes it works better, sometimes it works like on the video.

Dege wrote:

How can I Alt-Tab out from the game? I downloaded the latest version of your patch and I couldn't do that with the DX renderer.

Just delete nfs3.ini from the root directory. This file is used as a detector of NFS3 for automatic Windows Compatibility tool, and it disables Alt+Tab because the original version of the game doesn't like it.

Latest beta with dgdx6, dgdx7 and dgdx8 renderers is here: http://veg.by/files/nfs3/nfs3_modern_patch_dgbeta.7z

Dege wrote:

BTW, aren't you going to fix the fog in DX8 (and maybe DX5) drivers? 😀

DX8 uses a little bit different version of the Thrash API. DX5 is v104, DX6 is v105, DX6 from the NFS4 release is v106, DX7 is v107. DX8 is Thrash API v115. It seems that fog functions was changed a number of times during development of the Thrash API. For example, NFS3 works well with Thrash API v104 and v105, and it uses FOGMODE=4. But NFS4 uses FOGMODE=1, and it works ok with Thrash API v106 and v107 (DX6 from the NFS4 release and DX7). When I'm trying to use FOGMODE=1 in the NFS3, like the NFS4 does, the result looks like this with the DX7 renderer:

The same DX7 renderer renders fog effect well when it is used from the NFS4 (I've started NFS4 Modern Patch also). I don't know DirectX API enough to understand what's wrong. It seems, that I also have to fix something else to use FOGMODE=1 from the NFS3, as NFS4 does.

What is interesting, DX5 doesn't understand FOGMODE=4 and understands FOGMODE=1, and it looks like this (everything is in fog and there is no any spots without fog that DX7 has):

But DX5 looks like this not only in the NFS3, but in the NFS4 also. So, this FOGMODE=1 is different from the FOGMODE=1 which NFS4 uses with own DX6 and DX7.

You can see how DX7 looks with fogmode=1 using nfs3fogmode1.exe from the nfs3_modern_patch_dgbeta.7z (if you would like to see how it looks in action).

It seems, that DX8 have much more different handling of the fog calls. DX8 doesn't react to FOGMODE=1 or FOGMODE=4 at all. So I have to reverse engineer the Motor City Online to see how it enables fog with the DX8 renderer. Or there is some other error in the DX8 which causes not working fog.

Also I had tried to add native support of the windowed mode (without wrappers, it have to work even on Windows 98). And it works with the DirectX renderers. But when DirectX 5/6/7 renderers are used, Windows 7 disables Aero and switches to the Basic Theme for a some reason while the game is running 🙁

DirectX 8 renderer doesn't have this problem.

What a pity that Windows doesn't say what exactly it doesn't like when DirectX 5/6/7 renderers are used 🙁

Also it seems that glide3x.dll also have to support windowed mode controlled by the application, so I would like to try to use this feature directly from the game.

UPD. I've tried to pass 0xFF (GR_RESOLUTION_NONE) to the grSstWinOpen (dgVoodoo's glide3x.dll), and it seems that it treats it as 640×480. It is interesting to test how it works on the real Voodoo Rush.

VEG wrote:

Also I had tried to add a native support of the windowed mode (without wrappers, it have to work even on Windows 98). And it works with the DirectX renderers. But when DirectX 5/6/7 renderers are used, Windows 7 disables Aero and switches to the Basic Theme for a some reason while the game is running 🙁

Because DDraw could freely draw/overwrite arbitrary parts of the desktop (similarly to GetDC (NULL)) which is not compatible with desktop composition. Roughly, at the moment Windows detects that the application executes such an operation it shuts down DWM (what is not possible in Win8 and up by default, but you can insert a manifest into your application promising that you're going to be a good boy. 😀 )
The game probably doesn't allocate a DDraw clipper for the output window (needless for fullscreen mode) which allows overwriting the content of other windows covering that one, independently on the window z-order.

VEG wrote:

DirectX 8 renderer doesn't have this problem.

Yes, because DX8 cannot access any type of front buffers, only its back- and offscreen buffers.

VEG wrote:

What a pity that Windows doesn't say what exactly it doesn't like when DirectX 5/6/7 renderers are used 🙁

My tip is the missing DDraw hwnd clipper (not too complicated to create and attach one if you have a DDraw object instance).

VEG wrote:

Also it seems that glide3x.dll also have to support windowed mode controlled by the application, so I would like to try to use this feature directly from the game.

UPD. I've tried to pass 0xFF (GR_RESOLUTION_NONE) to the grSstWinOpen (dgVoodoo's glide3x.dll), and it seems that it treats it as 640×480. It is interesting to test how it works on the real Voodoo Rush.

Well, that's what the real Glide driver does: if the 'resolution' parameter is invalid (including GR_RESOLUTION_NONE) then it simply replaces it to 640x480.
The 3Dfx driver has a common internal video init function shared between DDraw and Glide which handles windowed mode and so GR_RESOLUTION_NONE too. But Glide always initializes in fullscreen in one of the predefined resolutions and does nothing with the incoming hwnd, just makes sure it can retrieve one that's not NULL.
I guess the documentation you cited only tells their late plans for the future, because Glide as an API is precious little for windowed mode.

As for the NFS3 fog, I didn't guess it's so complicated. 😀
Some day I check what's going on there. As I plan to do it for the DX8 thrash driver. Now I'm not sure that it doesn't use e.g. vertex buffers.
Messed up polygons must be the result of some invalid parameters pushed to one of the Draw calls.

Their plans for the future at the time... Voodoo Rush is actually a very early card. Bet that's gone in a Voodoo3-era reference? 😉