eierfrucht

My point is that (at least to me) it looks like Mode 1 is the untampered legacy DX7 renderer, quite broken on modern OSes if left unwrapped into a different...

> If the DLL loading test option doesn't work (obviously it doesn't work for cnc) It absolutely does work, above I posted screenshots from process explorer with wardd.dll (renamed cnc)...

BTW there may be another misunderstanding. Regardless of the rest of the issues, for cnc to work, any ddraw call exiting sfall and destined for SysWOW64\ddraw.dll must instead be explicitly...

>I just think if newer sfall 4 keeps wrapping ddraw calls to DX9 probably due to the built-in HRP code (which largely a reimplementation from Mash's HRP 4.1.8), And so...

>Not sure how easy it will be to chainload another ddraw.dll via source code changes, need to do some research. Maybe you can take a look at the code yourself...

Okay guys here's the deal... **Fixed files:** https://www.mediafire.com/file/5xt892ljfq0g065/sFall4.4.2%252Bcnc-ddraw.zip/file **File list:** ``` .\Shaders -- GLSL shaders for the OpenGL backend ddraw.dll -- patched ddraw.dll from sFall 4.4.2 ddraw.ini -- tweaked ddraw.ini...

It would suffice to add a second name like "wardd.dll" that takes precedence over "ddraw.dll" and that'll be it.

> On the contrary, we are getting rid of the hardcode, and such a solution will add shit A CustomDLLPath-like .ini parameter will either have to be left blank (unassisted...

> parameter must support relative file path with subfolder The stand-in library MUST reside in the same directory as the game executable. However a more correct solution would be to...