Closed ThirteenAG closed 6 years ago
Another interesting thing to add. If you use DxWnd and set Emulation in DirectX tab to Primary Buffer and then alt+tab quickly between desktop and the game you can see new frames I recorded it (yes had to use phone) https://www.youtube.com/watch?v=EGv6gIoRYNI
This shim seems to re-enable DDCAPS_OVERLAY which got disabled in Windows 8 and newer. Looks like the game cannot handle the case where it's not present correctly (it assumes failure, and then it stops releasing frames, leading to this crash).
Removing this check or applying this shim restores to Vista/7 behaviour of no movies displayed (looks like despite what some people say, movies probably never crashed on Vista and 7). Looks like the only hope for this is to replace directdraw hardware overlays used in there with d3d9 hardware overlays, introduced in Windows 7. No clue how complex this task is.
This was fixed in SilentPatchGF!
Wow, great work! I am going to have to see if any of the things done there would be useful for dxwrapper.
Feel free! Do note I initially wanted this to be a generic wrapper, but in the end I settled for a game specific solution. I'll also be publishing a rather extensive port mortem in a few days so I'll explain what exactly what wrong and how I approached the fix.
EDIT: Also note I'm aware of at least one incosistency with my "overlay emulator" - while I believe DirectDraw keeps the overlay posted after the first "Show" call and the subsequent ones are only acting as "update" calls, my implementation deletes and re-posts overlay from the render queue every time. While it is probably not a correct behaviour, it doesn't matter in the case of Godfather.
@elishacloud Finally published an article on the fix: https://cookieplmonster.github.io/2018/05/18/fixing-the-godfather.html
Perhaps this could be useful for dxwrapper, but for that you'd need to interoperate ddraw and d3d9 somehow...
Handy! Would have been useful for a Far Cry fix since writing those wrappers is fairly boring and repeatable.
Crash happens slightly after video starts playing on vista+ systems. Works on windows xp.
From my observations, something happens with video frames. Debugging shows that this is the last function executed (0x8C7520):
Basically, on windows xp, ( v1 == this + 44 ) never happens and everything goes fine, on win10 for example, first 1 or 2 frames gets processed like usual, then on 3rd frame v1 equals (this + 44) for some reason and it crashes.
Since it works on winxp, I'm not sure what kind of "bug" to look for. To avoid crash you can rename movies folder or write 0x75 at 0x8C7B13. That will skip movies.
I also tried to modify that VP6_CODEC_INTERNAL::GetFrameFromList function, so it always uses first frame pointer, that resulted in black screen appearing instead of video and audio worked fine.
Another way to get black screen with audio is to use shim:
That obviously won't work with any kind of windowed mode.