Myloch wrote:

I think that in usual Microsoft logic, things like directdraw are long dead and don't care a sxxt about making them run correctly anymore.

ZellSF put dgVoodoo's DDraw.dll in DOSBox folder to wrap its output to D3D11, so in this case, this has nothing to do with Microsoft's DirectDraw. I guess DOSBox's usage of DirectDraw is rather simple, so there shouldn't be compatibility issues using DirectDraw itself.

There are some things about dgVoodoo that are on to-do list, like when the app mixes DirectDraw and GDI. The way DOSBox uses DirectDraw might be another strange case.

With games in general, in some cases you can fix the game by changing some parameters passed to DirectDraw methods, so it can work correctly without a wrapper like dgVoodoo. There's also narzoul's DDrawCompat, which is all about tricks to make things work with native DirectDraw and friends (D3D up to version 7).

Myloch wrote:

I think that in usual Microsoft logic, things like directdraw are long dead and don't care a sxxt about making them run correctly anymore.

While that my be their underlying view, whenever I get too depressed about it they actually fix damage done and restore legacy compatibility like when flip flags were being ignored (I think that was the problem--the blitzbasic.com forum where it was detailed is now dead) in Windows 8/8.1 resulting in old DDraw games running around 30 fps max. Windows 10 came out with it fixed. I was only on Windows 8/8.1 for a year, but experienced far few legacy issues under 10 than under it. I'd be remiss to mention that of course, before MS fixed it, people like Dege did via wrappers. Sadly some issues will not be fixable.

galneon wrote:

Myloch wrote:

I think that in usual Microsoft logic, things like directdraw are long dead and don't care a sxxt about making them run correctly anymore.

While that my be their underlying view, whenever I get too depressed about it they actually fix damage done and restore legacy compatibility like when flip flags were being ignored (I think that was the problem--the blitzbasic.com forum where it was detailed is now dead) in Windows 8/8.1 resulting in old DDraw games running around 30 fps max. Windows 10 came out with it fixed. I was only on Windows 8/8.1 for a year, but experienced far few legacy issues under 10 than under it. I'd be remiss to mention that of course, before MS fixed it, people like Dege did via wrappers. Sadly some issues will not be fixable.

DirectDraw apps are still forced in so called maximized windowed mode, preventing them from running in real fullscreen mode and changing gamma unless you make a call to SetAppCompatData(12, 0). DDrawCompat does this, and some game specific patches as well. You can also use Compatibility Administrator and enable DXPrimaryEmulation shim with -DisableMaxWindowedMode parameter. Normal performance in this maximized windowed mode can be obtained on Win 8/8.1 with NoGDIHWAcceleration shim. One thing specific to 8.1, real fullscreen mode doesn't work when running with multiple monitors (extended mode), some strange bug with Desktop Window Manager. It's possible to disable DWM on 8.x with tricks, but it's not optimal thing to do. Or turn off all but the main monitor.

Besides those things, I haven't encountered any other practical difference between DirectDraw on Windows 8.x and 10. Windows 10 also breaks Direct3D 8 apps by forcing them into maximized windowed mode and there is NO option in the OS anywhere to turn it off, it only exists for Direct3D 9. The only way is around it is patching d3d8.dll. ThirteenAG's Ultimate ASI Loader does it at runtime. If he made a widescreen patch for your favorite game, then you're also covered.

Yes but I don't think AMD/Intel/NVidia would update pre-D3D9 driver components forever for their GPUs :p

So a "today tech" wrapper (not a "simple" fix-passthrough) is the best choice for the future.

True, inability to select dedicated GPU on Optimus laptops for older APIs is already a thing. I wonder if it takes anything to keep older APIs' status as it is today.

At least for OpenGL, NVIDIA said they won't remove any legacy functionality from their drivers. Though interfacing with Direct3D is somewhat (very?) different. Remember how Direct3D 11 level features can be accessed through OpenGL 4 even on Windows XP? No ties to newer WDDM.

I'm just curious about why something doesn't work. Knowing bells and whistles of those APIs also help make dgVoodoo better. Long time ago, MS promised backward compatible API and today we see things randomly breaking. All of this just to display bunch of pixels on the screen. 😕

UCyborg wrote:

DirectDraw apps are still forced in so called maximized windowed mode, preventing them from running in real fullscreen mode and changing gamma unless you make a call to SetAppCompatData(12, 0). DDrawCompat does this, and some game specific patches as well. You can also use Compatibility Administrator and enable DXPrimaryEmulation shim with -DisableMaxWindowedMode parameter. Normal performance in this maximized windowed mode can be obtained on Win 8/8.1 with NoGDIHWAcceleration shim. One thing specific to 8.1, real fullscreen mode doesn't work when running with multiple monitors (extended mode), some strange bug with Desktop Window Manager. It's possible to disable DWM on 8.x with tricks, but it's not optimal thing to do. Or turn off all but the main monitor.

Ahh, I think we're talking about the same problem. I was fuzzy on the details, but just found an archive of the old blitzbasic board including this thread (see jackfuste's posts).

I tried unsuccessfully at the time to make Dungeon Siege and some other games work using ACT as directed by him. Others were reporting it wasn't working either. It looked as though maybe a system update rendered the method from the thread unworkable, and it sounds like your addition of NoGDIHWAcceleration was the solution. I never read about that particular flag when I was struggling with the problem. Dungeon siege was actually a case of a game that worked at 60fps with a certain command line switch (bltonly=true), but this resulted in instability for me, and the Lazarus mod for DS is already unstable enough. 😜

Whatever the case, once I moved on to Windows 10, workarounds were no longer needed and my old DDraw games began working at 60 fps again. It was a legacy improvement out of the box for me. Didn't realize that about gamma, though. 😒

UCyborg, thanks for pointing out ThirteenAG. It is a great widescreen compatibility tool. I did not know about it. It has widescreen/compatibility fixes for 59 games.

I was able to chain ThirteenAG Widescreen Fix + dgVoodoo2 + nvidia inspector in Silent Hill 3. That way I got: widescreen + high resolution + high quality fog fix + DX11 upgrade + vsync + MSAA 8x + 16x Anisotropic filtering + bilinear blit stretch + phong shader + HBAO+. 😀 😀 😀

In order to enable HBAO+ in Silent Hill 3, use the following flags in Nvidia Inspector:
Ambient Occlusion Compatibility: 0x00060000 (Call of Juarez(DX10), Call of Juarez)
Ambient Occlusion setting: Performance (or select Quality/High Quality if you have a fast GPU)
Ambient Occlusion usage: Enabled

Dege, please take a look at the ThirteenAG fixes in github as you develop the dgvooodoo API (for splintercell and other games) and see if you can implement functions into the API that make it easy to port those scripts to dgVooodoo API. That way we can instantly start with 59 game specific fixes. 😀 And we won't have to chain wrappers.

https://github.com/ThirteenAG/WidescreenFixes … e/master/source
https://thirteenag.github.io/wfp

If it is not possible/difficult to port them into the upcoming dgVoodoo API, maybe you can just add ASI loading functionality. If ASI loading via dgVoodoo is not possible either, that's cool too. 😀

On a separate note, some of the fixes on ThirteenAG are for DirectX9 games, so it is not possible to use dgVoodoo with them yet. 🙁 Do you have any news/progress on dgVoodoo dx9 wrapper?

Another note about maximized windowed mode, MS uses it as a workaround for the issue with the black screen in the intro video in GTA 3 era games. I figured out a better approach, disable MS's fix with Compatibility Administrator, then create a new fix where on the page with compatibility fixes you select DXPrimaryEmulation shim, tick its checkbox, click Parameters button and type -RedirectPrimarySurfBlts under Command line. I can't remember which game it was, but sometimes disabling maximized windowed mode breaks things, otherwise it seems redundant with games that aren't doing anything weird.

Some try to run the monitor at specific refresh rate and if running at different refresh rate than the desktop is not desired, the result is unnecessary delay at startup and when alt-tabbing back. Here's the oddity I experience on my system. My main monitor refreshes at 59 Hz (or 59 point something), but 60 Hz is provided for compatibility. Trying to set 60 Hz always causes the delay, as it tries to set it, figures it's not working and reverts to 59 Hz under the hood, at least that's what I assume it happens (it always shows 60 Hz if it was selected). The delay occurs even if refresh rate is set to 60 both in Windows and in game. When both are at 59, everything is fine. Before, I had Windows 7 and ATI card instead of NVIDIA and there was no such delay with 60 Hz, or at least it was significantly smaller, don't remember exactly, certainly wasn't anywhere near 2 seconds. I haven't dug any deeper into this. There's also this trick for NVIDIA users, seems to remove delay at 60 Hz, but it made mouse response worse with VSync, despite setting the frame limit 2 frames below the refresh rate. Guess I'm not missing anything with sticking to 59 Hz.

Anyway, GTA 3 era games try to refresh at 60 Hz. Been messing with GTA: Vice City recently and if I patch the byte in gta-vc.exe at offset 0x200c5d from 0x3C to 0x3B (that is, 60 -> 59), the delay is gone.

BTW, dgVoodoo's DDraw isn't picked up for those GTAs out-of-the-box (only used for intro videos), despite removing absolute paths to ddraw.dll in registry. quartz.dll is involved, so it's a known issue and can be avoided by using Compatibility Administrator to apply InjectDll shim and specify ddraw.dll as parameter. So here are some screenshots from GTA: Vice City, should work with III as well since it's also a D3D8 game (San Andreas is D3D9), but I haven't set it up yet.

And the files in my game's folder:

We have:

• dgVoodoo's DLLs
• dsound.dll - Creative ALchemy to restore 3D sound
• fdraw.dll - Silent Patch ddraw.dll component (renamed from ddraw.dll to be able to use dgVoodoo, also necessary without dgVoodoo so ddraw compatibility fixes can be applied, they are not when proxy ddraw.dll is in place)
• gta-vc.exe - game executable file, patched to load fdraw.dll instead of ddraw.dll (can be done with simple text editor)
• GTAVC.WidescreenFix.asi - ThirteenAG's widescreen patch
• Mss32.dll - Miles Sound System library, patched to load dsound.dll from game folder rather than system DLL (search for "vice city alchemy fix") This DLL also loads DLLs in game folder with .asi extension, so no separate ASI loader is needed for mods that inject their own code into the game.
• SilentPatchVC.asi - Silent Patch, the main part with majority of patches
• VC.CLEO.asi - some mods are based around CLEO framework, I don't have any such mod ATM, but may come in handy in the future

As mentioned before, I used Compatibility Administrator as well to disable MS's fixes for the game and applied the following:

• DXPrimaryEmulation with "-RedirectPrimarySurfBlts" parameter (without quotes) - needed only to avoid black intro screen on Windows 8+ with native ddraw.dll after disabling MS's maximized windowed mode fix
• InjectDll with "DDraw.dll" parameter (without quotes) - ensures dgVoodoo's DDraw.dll is used for intro cinematics

UCyborg, in my opinion, that's worth a decent write-up in "Windows" when you have a chance, since it touches on things well beyond dgVoodoo2: Windows

You're right, got carried away a bit, my intention was just to show that it works, point out possible workaround for dgVoodoo not being used when DirectShow was involved and the fdraw.dll trick since we have a well known patch for the game that comes with custom ddraw.dll, so you can't use both without minor tweaks.

With that said, GTA: Vice City is pretty lightweight game with virtually zero issues related to rendering, otherwise someone would have probably brought it up before. I imagine most folks don't notice/care about some small details.

I think Stiletto was suggesting that was a very useful post and deserves greater exposure. I agree.

galneon wrote:

I think Stiletto was suggesting that was a very useful post and deserves greater exposure. I agree.

Yes, that's exactly what I meant. If there's gonna be people around here applying "compatibility fixes" to death to games, be it Win9x games on XP or WinXP games on Win10, may as well do a decent write-up on one of the first forums on the Internet to host such write-ups. 😁

Dege, I have a simple request regarding pixel perfect integer scaling. Can you add a scaling mode that upscales the image using an ISF factor that is beyond the maximum display resolution and then downscales to the maximum screen resolution by bilinear interpolation while preserving aspect ratio? You can call it "MAX ISF with downscaling" or something. This will be similar to the "near pixel perfect" method of the Dosbox ECE build.

Since my laptop's maximum resolution is 1366x768, I am not even able to use 2x ISF in most of the games. If a game has 640x480 resolution, 2x ISF gives 1280x960 which is larger than the maximum 4:3 resolution of 1024x768 that my display supports. With this "Max ISF with downscaling" mode, dgVoodoo will first upscale the 640x480 game to 1280x960 using ISF (or it will force the resolution if the game engine supports it), and then downscale it to 1024x768 using bilinear interpolation. You can use another downscaling interpolation method, if you believe that it will give better results.

Been in the Insider's beta thing for Win10x64 since 10/2015--little over two years now. (Man, does time fly!) Anyway, got a multi TB game library of > 350+ games installed, from 30 years old to releases in the last couple of months--aside from DG Voodoo2 & Nglide 1.05, oddly enough, I have zero problems with game compatibility--note that I have been replacing all of my old titles with GOG versions when possible over the last few years. Obviously some of the *original* old stuff would have a prob with WIn10x64--but not after GOG-laundering.

Specifically a game which I cannot part with for some reason--Lands of Lore 2--a Dosbox GLIDE affair--isn't working well anymore, neither program runs it for more than a few minutes before it crashes with memory errors out of the yin-yang--I'm now running version 1709 (Fall Update), build 17025. They seem to have done something with d3d/dx code that manages not to present compatibility problems yet is choking my GLIDE emulators...😉 Before these latest builds--I could run the game for hours with either program without a problem.

Running an RX-480-8GB, Crimson 17.11.1, FX8320e, 16GB system ram. Have been reading this thread with interest and thought to chime in with my experiences! Have also commented on this in the Win10x64 Microsoft hub as well.

Waltc wrote:

Been in the Insider's beta thing for Win10x64 since 10/2015--little over two years now. (Man, does time fly!) Anyway, got a multi TB game library of > 350+ games installed, from 30 years old to releases in the last couple of months--aside from DG Voodoo2 & Nglide 1.05, oddly enough, I have zero problems with game compatibility--note that I have been replacing all of my old titles with GOG versions when possible over the last few years. Obviously some of the *original* old stuff would have a prob with WIn10x64--but not after GOG-laundering.

Specifically a game which I cannot part with for some reason--Lands of Lore 2--a Dosbox GLIDE affair--isn't working well anymore, neither program runs it for more than a few minutes before it crashes with memory errors out of the yin-yang--I'm now running version 1709 (Fall Update), build 17025. They seem to have done something with d3d/dx code that manages not to present compatibility problems yet is choking my GLIDE emulators...😉 Before these latest builds--I could run the game for hours with either program without a problem.

Running an RX-480-8GB, Crimson 17.11.1, FX8320e, 16GB system ram. Have been reading this thread with interest and thought to chime in with my experiences! Have also commented on this in the Win10x64 Microsoft hub as well.

Have you tried directx version?
LoL2 have a win95 directx version.

i have tried and it works with win10 fall update. Only CGI are jerky.

willow wrote:

Have you tried directx version? LoL2 have a win95 directx version. […]
Show full quote

Waltc wrote:

Been in the Insider's beta thing for Win10x64 since 10/2015--little over two years now. (Man, does time fly!) Anyway, got a multi TB game library of > 350+ games installed, from 30 years old to releases in the last couple of months--aside from DG Voodoo2 & Nglide 1.05, oddly enough, I have zero problems with game compatibility--note that I have been replacing all of my old titles with GOG versions when possible over the last few years. Obviously some of the *original* old stuff would have a prob with WIn10x64--but not after GOG-laundering.

Specifically a game which I cannot part with for some reason--Lands of Lore 2--a Dosbox GLIDE affair--isn't working well anymore, neither program runs it for more than a few minutes before it crashes with memory errors out of the yin-yang--I'm now running version 1709 (Fall Update), build 17025. They seem to have done something with d3d/dx code that manages not to present compatibility problems yet is choking my GLIDE emulators...😉 Before these latest builds--I could run the game for hours with either program without a problem.

Running an RX-480-8GB, Crimson 17.11.1, FX8320e, 16GB system ram. Have been reading this thread with interest and thought to chime in with my experiences! Have also commented on this in the Win10x64 Microsoft hub as well.

Have you tried directx version?
LoL2 have a win95 directx version.

i have tried and it works with win10 fall update. Only CGI are jerky.

I'll keep looking--yes the DX version is easy to install, even the DOSbox version. Just nowhere near as good looking as the GLIDE version. I'll keep looking.

willow wrote:

Have you tried directx version? LoL2 have a win95 directx version. […]
Show full quote

Waltc wrote:

Been in the Insider's beta thing for Win10x64 since 10/2015--little over two years now. (Man, does time fly!) Anyway, got a multi TB game library of > 350+ games installed, from 30 years old to releases in the last couple of months--aside from DG Voodoo2 & Nglide 1.05, oddly enough, I have zero problems with game compatibility--note that I have been replacing all of my old titles with GOG versions when possible over the last few years. Obviously some of the *original* old stuff would have a prob with WIn10x64--but not after GOG-laundering.

Specifically a game which I cannot part with for some reason--Lands of Lore 2--a Dosbox GLIDE affair--isn't working well anymore, neither program runs it for more than a few minutes before it crashes with memory errors out of the yin-yang--I'm now running version 1709 (Fall Update), build 17025. They seem to have done something with d3d/dx code that manages not to present compatibility problems yet is choking my GLIDE emulators...😉 Before these latest builds--I could run the game for hours with either program without a problem.

Running an RX-480-8GB, Crimson 17.11.1, FX8320e, 16GB system ram. Have been reading this thread with interest and thought to chime in with my experiences! Have also commented on this in the Win10x64 Microsoft hub as well.

Have you tried directx version?
LoL2 have a win95 directx version.

i have tried and it works with win10 fall update. Only CGI are jerky.

You can fix jerky CGI with some compatibility flags. I can never remember which though.

dgVoodoo2 has some minor rendering problems with Lands of Lore II unfortunately. You can also play it with DXGL, but that has different rendering problems and DXGL doesn't allow forcing rendering resolution yet.

Is there a list of games that can take advantage of dgVoodoo's Phong shading option?
Or at least some known examples 😀

Waltc wrote:

willow wrote:

Have you tried directx version? LoL2 have a win95 directx version. […]
Show full quote

Waltc wrote:

Been in the Insider's beta thing for Win10x64 since 10/2015--little over two years now. (Man, does time fly!) Anyway, got a multi TB game library of > 350+ games installed, from 30 years old to releases in the last couple of months--aside from DG Voodoo2 & Nglide 1.05, oddly enough, I have zero problems with game compatibility--note that I have been replacing all of my old titles with GOG versions when possible over the last few years. Obviously some of the *original* old stuff would have a prob with WIn10x64--but not after GOG-laundering.

Specifically a game which I cannot part with for some reason--Lands of Lore 2--a Dosbox GLIDE affair--isn't working well anymore, neither program runs it for more than a few minutes before it crashes with memory errors out of the yin-yang--I'm now running version 1709 (Fall Update), build 17025. They seem to have done something with d3d/dx code that manages not to present compatibility problems yet is choking my GLIDE emulators...😉 Before these latest builds--I could run the game for hours with either program without a problem.

Running an RX-480-8GB, Crimson 17.11.1, FX8320e, 16GB system ram. Have been reading this thread with interest and thought to chime in with my experiences! Have also commented on this in the Win10x64 Microsoft hub as well.

Have you tried directx version?
LoL2 have a win95 directx version.

i have tried and it works with win10 fall update. Only CGI are jerky.

I'll keep looking--yes the DX version is easy to install, even the DOSbox version. Just nowhere near as good looking as the GLIDE version. I'll keep looking.

I think the last version of the game (1.30) have the same graphics in direct3d and in glide mode. I didn't see any difference.
The problem at home with nglide version is that after some minutes, the game is very jerky (i have tried in win7 or 10 with differents version of dosbox same thing) 30 fps to 12-13 fps.

ZellSF wrote:

You can fix jerky CGI with some compatibility flags. I can never remember which though.

Do you know how modify compatibility flags?