Are you having compatibility and performance issues with old DirectDraw/Direct3D games on newer versions of Windows? Me too. Especially since upgrading to Windows 8.1.

I know there are like a dozen existing ddraw.dll wrappers already attempting to fix some of the issues, but I wasn't quite satisfied with the ones I tried. So here's another attempt... feel free to borrow some ideas/code for your own projects. (Thanks for the link, I couldn't post it directly due to too low rep or something)


To install, just copy the ddraw.dll file to the game's directory (next to the .exe file). If there is already a ddraw.dll there, you can try to replace it - it may or may not work, so make a backup first.
To uninstall, just delete the dll (replace it with old one, if there was one).
Don't try to install in your Windows system folders, it won't work.

There are no configuration options and I hope to keep it to a minimum in the future too (assuming I make any future improvements at all).

DDrawCompat is mainly focusing on graphical issues and performance, not on adding fancy new features like windowed mode (see e.g. DxWnd for that).
As it is a DirectDraw wrapper, it's only useful for games using DirectX versions 1 to 7. That includes some older Direct3D renderers.

Please note that I only did testing on Windows 8.1 (with an Nvidia GTX 760), but I'm hopeful it would work on at least Vista and above (maybe with a few adjustments). Windows XP (and below) is not likely to be supported (and I don't intend to change that since it's officially an unsupported OS for a while now).

Obviously, there is absolutely no warranty and I take no responsibility for any potential damages. Use at your own risk.

Below are a list of games I tested (very briefly, mostly the beginning) and some of the related issues that should be fixed (at least on my test system, heheh). Performance improvements should be applicable to all so I won't mention that separately for each.

Arcanum (GOG): the game's main screen was broken for me with the already provided wrapper - it should be ok to replace the existing ddraw.dll (make a backup first!)
Deadlock 2 (GOG): fixed screen going (mostly) black when mouse is moved
Diablo II: Direct3D renderer performance improvement
Divine Divinity (GOG): Direct3D renderer performance improvement
Fallout Classic (GOG): restored missing palette animations (screen fade-out/fade-in effects)
Gorky 17 (GOG): fixed some graphical glitches, some still remain... I still get some black boxes covering the characters but even that seems to be magically fixed after alt-tabbing once (previously alt-tabbing broke the game screen completely)
Icewind Dale 2 (GOG): fixed flickering cursor and hardware mirroring (so-so, software might still be faster, haven't noticed any issues though)
Nox: fixed flashing/corrupted screen when entering the main menu (probably Nvidia specific issue)
Planescape Torment (GOG): fixed hardware mirroring (as in IWD2)
Red Alert: fixed flickering in menus (when not using the already available wrappers)
Sacred Gold (GOG): performance fixes; seems to have trouble alt-tabbing after the main game is entered though
StarCraft: Brood War: fixed broken Battle.net interface - though people say you can get banned (at least on the official servers) for using even DirectDraw wrappers, so beware (I never bothered making an account so I didn't test beyond the login screen; I also don't know whether a potential ban is permanent or just a kick or whatnot)

If you run into issues (which you likely will), don't despair... the project is open source so someone may eventually fix them. :P

For developers:
There should be a ddraw.log file generated next to the dll if it's installed properly, you can possibly find some clues there. Logging is very minimal in the release build though (mostly just some errors logged and only once per session). The debug build however (not included) is VERY verbose, it can generate hundreds of MBs of logs quickly in some cases, watch out. (Logs every hooked function entry/exit among others).
The project was created with Visual Studio 2015. Microsoft's Detours library is the only real external dependency for compilation (maybe some Windows/DirectX SDKs need to be installed too, I don't remember what's already included with VS).

Maybe I'll add some forgotten details later after I had some sleep...

Is this it?
https://github.com/narzoul/DDrawCompat

Ifthis works on Tony Hawk's Underground 2, I will be impressed.

Yeah, thanks! I don't have that game to test, but according to the system requirements it uses DirectX 9, so it shouldn't make any difference. This is for DirectDraw based games only (DirectX 1-7).

Where is actual ddraw.dll file? I only found the initial folder with source files.

Great project, i'll look into it when i have some free time.

Click on the release link in the bar directly above the "New pull request" button (or just add /releases at the end of the project link).

Thanks.

I tried immediately with Deadlock 2 as I have that black screen issue in Windows 7 and now it seems to work.

I'm going to try with Messiah, Nox and Chicago 1930 as those games I've never been able to get to work properly under Windows 7.

Please report back on your results with Messiah, as I have never gotten that to work either.

Wonder if it'll work with Captain Claw. Someone told me to use a DirectDraw wrapper around it to fix the slowdown in Windows 8 (now Windows 10), but I don't have the game at the moment...

Will do.

I tried it a minute ago with Chicago 1930, I always had a weird performance/mouse issue where I would reduce performance to some 1FPS if I moved the mouse very fast. Now it's the opposite, the faster I move the mouse the closer to optimal performance I'm getting but good enough if I don't move at all: very impressed!

Edit: I managed to get Messiah working now but I doubt it's because of the ddraw.dll because I'm using the nGlide wrapper with Win98 comp. mode, the D3D exe just wants to crash in different ways depending on settings (black screen, instant crash, slow crash, waiting crash..) What's annoying though is that settings doesn't seem to save other than Controls. Music for example is extremely loud.

D3D seems to work for me as long as it's launched with the "+!" command line option (otherwise it crashes before the main menu is loaded). Without DDrawCompat it runs in a maximized window with borders though. This can alternatively be fixed via Microsoft ACT (Application Compatibility Toolkit) using the "DXPrimaryEmulation -DisableMaxWindowedMode" fix (DDrawCompat enables this automatically).

However, with the ACT fix the 3D elements will mostly be missing (black) after alt-tabbing. It seems to be a bug in Messiah: it forgets to restore some lost vertex buffers after getting back in the game. This is currently not a problem with DDrawCompat because it seems I also have a bug in my code (oh, the irony) that prevents creating vertex buffers in video memory, so the game falls back to system memory which is not affected by alt-tabbing. I'll try to find a proper fix for that eventually, for now I'll leave it this way for better compatibility.

Nevertheless it may be better to stick to nGlide with this game if it has less issues for you.

I also have the problem with settings not being saved, I have no idea what to do about that.

Tried it with Captain Claw. The game before I placed in the dll was okay in the menus but terribly slow in-game. After I put in the dll, the game is now pretty much playable with the speed it was intended to play at. However, the screen tearing is obviously visible.

But anyways, thanks for the effort!

How does this wrapper work? Does it translate the DirectDraw calls to something else (e.g. OpenGL)? There is a long-standing issue with older Windows games in Wine on OS X. If you don't know, Wine is a compatibility layer to run Windows-programs on non-Windows OSes.

The issue from what I understand is that Wine translates DirectDraw calls to OpenGL by creating a double-buffered context but only renders to one of the buffers and never swaps them. It's a weird thing to do, but it's legal. Apple's OpenGL implementation assumes that any double-buffered context would use both buffers and keeps switching them on its own, resulting in flickering where half of the image is random memory garbage.

I'm interested in whether a DD wrapper could fix this. Newer games (Direct3D 9+) don't have the flickering problem. I tried your DLL and games were still flickering, but if you need someone for testing let me know. I would love this problem to be finally solved one way or another.

DDrawCompat does not use any external renderer, it only makes adjustments to how DirectDraw (and GDI) is used internally. The kind of flickering you mention (with every second frame being garbage) should not happen. Are you sure the game you are testing uses DirectX 7 or lower? If there is no ddraw.log file created when launching the game, then it probably doesn't. Which game is it?

As for the other type of flickering/tearing (as mentioned by PookaMustard) due to the lack of V-sync, it is game dependent. Games that don't use double (or triple) buffered rendering do not naturally support V-sync. It may be possible to hack it in regardless, but it's tricky and requires precise timing, and if not done correctly it can break currently working games. I'll experiment a bit with it anyway.