search

narzoul / DDrawCompat

DirectDraw and Direct3D 1-7 compatibility, performance and visual enhancements for Windows Vista, 7, 8, 10 and 11
BSD Zero Clause License
880 stars 67 forks source link

Primary surface error #255

Closed PrgmrAtHrt closed 7 months ago

PrgmrAtHrt commented 7 months ago

As of 0.5.0 any application I run that uses ddraw.dll gives an error related to drawing of the primary surface. I was not having any issues prior to this new release.

DDrawCompat-SWEP1RCR.log

narzoul commented 7 months ago

This game works fine on NVIDIA and AMD, but I don't have an old Intel integrated GPU to test anymore. According to your log, the depth buffer creation fails, which is very odd.

Please upload debug logs by adding "LogLevel=debug" to DDrawCompat.ini.

Zerodarkage commented 7 months ago

I have a Intel HD Graphics (by Dell) and since 0.5.0 all games with the updated DDrawCompat does not work anymore. Some games have only sounds, Others say I don't have DirectX installed. Here is a debug log file of Nocturne!

P.S. I hope you don't mind I'm using an already open issue.

DDrawCompat-nocturne.log

PrgmrAtHrt commented 7 months ago

Here is a debug log as requested

DDrawCompat-SWEP1RCR.log

narzoul commented 7 months ago

I guess there is a similar root cause between your two issues, because in both cases there are no calls to the driver's pfnCreateResource or pfnCreateResource2 functions, which is not normal. I can't figure out why though. Both of your drivers seem very outdated, but since it worked in v0.4.0, that shouldn't be the main problem.

I don't have a better idea at the moment, than to narrow down the scope to the first commit that introduced the problem between v0.4.0 and v0.5.0. I uploaded an archive of builds of all commits between those versions, under the v0.5.0 release, named as "debug-previous-builds". Here's also a direct link: https://github.com/narzoul/DDrawCompat/releases/download/v0.5.0/DDrawCompat-v0.5.0-debug-previous-builds.7z

I went with 7-zip instead of normal zip this time, because it's 9.4 MB instead of 67.4 MB, I hope that's not a problem, but you can get 7-zip from here if you don't already have it: https://www.7-zip.org/

The builds in the archive are numbered from oldest (v0.4.0-1-g19899f81) to newest (v0.4.0-86-g10d1a3a9). Please try to figure out which was the last working and first broken build. You don't have to try them one by one of course, if you know how to do logarithmic search. Start in the middle, if it looks good, jump to the middle of the newer half, if not, jump to the middle of the older half, etc. to keep narrowing down the range to half of the previous candidates.

Zerodarkage commented 7 months ago

This is the result! v0.4.0-29-g12c4f87c - Works! (For multiple games!) v0.4.0-30-gdefdfafe - Does not work properly! (Same errors from the version 0.5.0)

narzoul commented 7 months ago

Wow, that was fast!

It does give me an idea too. I suppose the problem is caused by that D3DDDIFMT_UNKNOWN format under "Supported resource formats" in the log. I just realized that the order in which these formats are printed is not the same as the order originally returned by the driver. It was sorted by the numeric format IDs before printing.

It could be that the Intel driver originally returns this invalid format at the last place, but in the first broken commit you mentioned, the code was altered to return the results to the runtime in the same sorted order that is seen in the logs. It's quite likely that when the runtime encounters this unknown format, it assumes there is a driver bug and stops enumerating the rest. This would explain why it doesn't try to create any resources in the driver and just attempts to emulate every format in software instead.

Here's a quick fix where I just skip the enumeration of that unknown format for now. Hopefully this will solve at least some of the problems: ddraw.zip (diff.txt compared to v0.5.0)

Let me know if this works any better. If there are still issues, please upload debug logs again.

Zerodarkage commented 7 months ago

Unfortunately did not work. (Same problems from version 0.5.0) Here is the Debug Log (Nocturne) DDrawCompat-nocturne.log

PrgmrAtHrt commented 7 months ago

My results are the same as Zerodarkage.

DDrawCompat-SWEP1RCR.log

narzoul commented 7 months ago

Ugh, looks like this was a false track, D3DDDIFMT_UNKNOWN does not cause any problems, at least when I tested it on my NVIDIA driver.

I finally found a bug which may be responsible, so here is the next fix attempt: ddraw.zip (diff.txt compared to v0.5.0)

Even if it works, please upload at least info level logs. I changed the way supported resource formats are printed, and I'd like to see what happens on these Intel drivers exactly.

Zerodarkage commented 7 months ago

Yes!!! It Works!!! Here is the debug log (Nocturne) DDrawCompat-nocturne.log

P.S. Thank You Very Much!

PrgmrAtHrt commented 7 months ago

Works great now!

DDrawCompat-SWEP1RCR.zip

narzoul commented 7 months ago

I made a new release (v0.5.1) including this fix, since I suppose it will be a problem for many people. @PrgmrAtHrt @Zerodarkage @horxd33 Thanks a lot for the good reports and for helping to debug this issue!