d3d9to8

An experimental demake layer from the more "modern" D3D9 to D3D8, wherever/however possible.

Not to be confused with the much more useful d3d8to9. This wrapper goes the other way around, against all logic and common sense.

Known limitations include:

D3D9Ex, though it might be convinced to work to some degree at a later date
Use of any SM2+ programmable shaders
Use of SM1 declarations with unsupported register types (e.g. D3DDECLUSAGE_TANGENT) or integer/boolean constants
Calls to StretchRect that actually do stretching or format conversions (the vast majority will)
Any form of D3D9 specific resource sharing
Surface calls to GetDC/ReleaseDC
Use of various D3D9 exclusive sampler/texture stage states
Surface/texture formats unique to D3D9, such as D3DFMT_A16B16G16R16F
Multiple swapchain use (thankfully, it is rare even in D3D9)
Use of various D3D9 exclusive render states which directly impact rendering
SetStreamSource calls using offsets
SetStreamSourceFreq calls, used for instancing
Use of multiple simultaneous render targets
DrawIndexedPrimitive calls using a negative BaseVertexIndex (should be quite rare)
Other minor D3D9 exclusive API calls, with specific paths which can't be implemented in D3D8

Important

Please don't submit issues or treat this as an entirely serious project, because it's not. It will work at times, especially with early D3D9 games, but in the vast majority of cases it's not expected to work properly/correctly. Its purpose is mainly for testing and bringing otherworldly things into existence, such as 64-bit D3D8.

FAQ

What possessed you to create such an abomination?

Why the dark forces of Chaos, of course. No, it was my love for D3D8 mostly, and an unnatural curiosity. My original goal was to get W40K: Dawn of War - Definitive Edition in a workable state with D3D8, because it is a 64-bit D3D9 game, and 64-bit D3D8 doesn't actually exist. It would have been a nice test use case, however outside of a partially rendered main menu, it crashes when trying to start a game, due to known limitations that have made their way into the remastered version.

Are there any known working games?

Among known fully working titles, I can mention:

W40K: Dawn of War (the original tetralogy, including Soulstorm)
W40K: Fire Warrior
Aliens versus Predator (Classic 2000)
Gun
The Lord of the Rings: War of the Ring
Emperor of the Fading Suns Enhanced
Machinarium (legacy DX9 version)
Sid Meier's Pirates! (Live the Life) (with shaders disabled)
Majesty HD
Outcast 1.1
Battle Engine Aquila
Children of the Nile ("Fixed" shadows only)
Freedom Force vs The 3rd Reich
Beyond Divinity
Seven Kingdoms: Ancient Adversaries
Amnesia: Memories
Close Combat: Gateway to Caen / Panthers in the Fog (if you can put up with some missing UI element backgrounds)

...and a few others. The list might expand in the future, but probably not by a lot.

Since we report the same capabilities that a D3D8 level card would report to these D3D9 games, we rely on them having fallback paths for such cases. Many later D3D9 games do not, and will outright refuse to run. Some may run with some degree of visual artifacting, or crash at later points in time, when they run into something unexpected.

Will it work on Windows?

It should work just as well as on Linux/Wine, for the most part.

How do I use it?

Simply dropping it next to the game executable will work fine in most cases. It will rely on an existing D3D8 implementation (hence a d3d8.dll) being present in your system path.

Warning

64-bit D3D9 titles have no chance of working on Windows, since it does not provide a 64-bit implementation of D3D8.

Is there any benefit in running those games with D3D8 as opposed to D3D9?

None whatsoever. D3D8-capable cards can still run D3D9 just fine, but with limited capabilites, so many games will refuse to start. In that regard, d3d9to8 can do no magic. In truth, you'd have better luck by sticking with D3D9 in such cases .

Will d3d9to8 work with DXVK?

Yes and no. Not with upstream DXVK, because its d3d8.dll will in turn rely on loading DXVK's d3d9.dll... but d3d9to8's d3d9.dll will already have been loaded, hence that will quickly end up in an infinite recursion and/or crash.

I was able to get it working with a statically linked DXVK d3d8.dll, much like D8VK was distributed originally. I may include such binaries as part of any d3d9to8 releases for convenience.

What about games using SM2+, can't you translate all that to SM1?

No. I may be crazy, but I'm not that crazy. And in many cases that's an actual technical impossibility.

Are there any options I can tinker with?

Not at this point, and I don't think I will add any in the future. This isn't that useful of a shim to be perfectly honest.

Will there ever be a d3d9to7?

I sure hope not.

I have a game that doesn't work, should I report an issue?

There's really no point, it is what it is. Games will either work or they won't, for various reasons. It's a roll of the die when it comes to how game code handles missing D3D9 features, or if that happens at all.

WinterSnowfall/d3d9to8

README