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:
- 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