Black screen - experimental version

[Ombret4c]

Hello,

I copy the last ddraw.dll on my game folder but i have a black screen when I launch game. The game is https://godofnea.com

It's a directdraw7 game. Without ddraw the drawing of game is 70-100ms.... I have windows 10 with the last updates.

Can you help me please ?

[ddraw.log](https://github.com/narzoul/DDrawCompat/files/3314238/ddraw.log)

[narzoul]

I will look into it later (possibly much later, I have a lot of other unfinished tasks). Have you tried the v0.2.1 release? It seems to not have the black screen issue, at least on my system. I can't say much about performance because I didn't create an account yet. The mouse feels a little sluggish but maybe that's just how the game is supposed to be.

[Ombret4c]

You can write " !fps " in game to see your fps and drawing. the mouse is meant to be fluid and the game too. on a windows 7 configuration, the drawing is around 7-8-9 ms. the fps is at 32.

I tested a previous version, there is no black screen is true, but the game is slow (windows 10).

It has been several months since I am on this problem. you are a bit my last chance.

[narzoul]

The black screen issue is fixed in latest experimental release. However, I can't reproduce the performance problems. Is that still present?

[Ombret4c]

Thank you so much for your return! I was able to test your last release, I have no problem black screen!

I have performance problems. The game on my old PC with Windows 7 is very fluid, but on my recent PC with Windows 10 it is very slow (+20ms of drawing versus 6ms of drawing on Windows 7)

I had an old PC under Windows 10 that allowed to have the game very fluid, I guess it came from the graphics card (or driver) that still managed directx7 ...

If you have a little time to try to find a solution it would be really amazing for me.

[Ombret4c]

with the sources of the game will that help you? its c++ on vs2017

will I have a way to contact you?

[narzoul]

Thanks, but it probably wouldn't help. It's most likely down to hardware/driver differences since I'm getting pretty good performance on Windows 10. Or maybe you're not testing in the starting area and the game is much more demanding where you are?

Anyway, I just updated the experimental release again, and it gives me a pretty significant performance boost. Drawing times in the starting area are down to 3-5 ms from 9-14ms. Hopefully it will bring similar improvements for you.

[Ombret4c]

I was able to get your release, under Windows 7 I'm at 23ms of drawing in the starting area with the dll :(

without the dll I am 8ms. I could test with windows 10 but the problem is worse, with or without, I'm 35ms

there is really a big problem with the graphics engine of this game that uses very old dx7 instruction I would not be what to change in the source code

at one time I tried WineD3D, the game was really very smooth, 7-8ms with windows 10 (on the recent computer), but all the text of the game did not work anymore! I wonder if it is not the interface of the game or the display of texts that is poorly managed under Windows 10 and makes the game slow.

I have abused a lot of your time and I understand you are moving on. if you ever have free time it would be great, I would come see your project on github. maybe you'll find the right setting, I do not know ...

[narzoul]

Okay, just to make sure: you're not using any of the dlls from the ReleaseWithDebugLogs or Debug directories for performance testing, are you? Those are obviously much slower than the Release version because of the extra logging.

Do you know where the game stores its configuration files? If yes, could you send yours to me? Or just take screenshots of the config from the gonconfig.exe window and also the in-game options window, if possible (you should be able to use the Alt+PrintScreen key combination to capture only the active window).

If you are using the Release build, then switch to the ReleaseWithDebugLogs build and capture about 5 seconds of gameplay from the in-game world, preferably with a character which is already in the starting area. Then exit the game as quickly as possible to keep the log file to a minimal size. It might still be quite big (around 200MB). Compress it and attach here, please.

[Ombret4c]

Yes, yesterday I used the normal release.

Configuration files is here in C:\Users\Paul\Documents\Dialsoft\

I can realize the test that you asked me with the ReleaseWithDebugLogs, I attach you a zip archive include screenshot for gonconfig.exe + gon.exe + ddraw.log ddraw_debug_gon_win7.zip

[narzoul]

There are a lot of odd things in that log. What kind of video card are you using exactly? From the logs, it seems to be something from AMD, and your Windows 10 system has Intel? Do you know the exact model for each? Are the drivers up to date?

Anyway, I think the Windows 7 and Windows 10 issues are probably quite different. Could you please take similar logs also from Windows 10?

So far, based on your Windows 7 logs, I think these are the main causes of performance problems there:

1. Your video card doesn't seem to support hardware-accelerated blitting from video memory to system memory, at least for off-screen plain surfaces. I wonder if it's equally slow for textures, this would be worth some additional testing. I'll try to create some quick test release for this soon.

2. Your video card doesn't seem to support hardware-accelerated color conversion from 16 bit to 32 bit either, which is rather odd... but I guess this normally isn't really needed until Windows 8+. But this game seems to use this feature anyway, which makes me think it was written specifically for Vista+, as I think earlier versions of Windows didn't even support such color conversions in DirectDraw. However, it might be possible to get around this problem by doing the conversion via a pixel shader. The problem is, this is not supported by DirectDraw so it would have to be implemented at the driver level, and I didn't quite plan to get into that until after v0.3.0. Maybe doing the conversion in software would be feasible until then, but the problem is I don't know how to detect video cards that would need this, and I don't want to make the performance worse for everyone else by this.

3. There is an inexplicable stall in D3DKMTPresent, curiously lasting ~16 ms every time when blitting from a video memory surface to a window, which is probably done once per frame. I'd guess it's waiting for v-sync, but I thought that should never happen for a windowed blit. But just in case, do you have v-sync forced on in your drivers? Can you try forcing it off? Or do you use other third-party software like RivaTuner that might interfere? Also, the "rotate" flag is set. Is your monitor rotated? Can you try rotating it back if it is?

Check if any of the above helps with the performance in Win 7. Meanwhile I'll try to create a test version for the texture blits mentioned in the first point.

However, I feel like it might be better to focus on Windows 10 first, as the Win 7 case seems a bit hopeless to fix quickly.

[narzoul]

One more thing for Win 7: is desktop composition enabled or disabled while the game is running? If it's enabled, can you try disabling it and vice versa? This might also be related to point 3 above.

Unfortunately I haven't had a Windows 7 system for testing for a long time now, so turning off desktop composition is not really supported by DDrawCompat, and might not even work correctly, if at all...

[narzoul]

Here is the quick test version based on texture blitting, along with the source code diff on top of commit 8cc73dc: ddraw-debug-gon.zip ddraw-debug-gon-diff.txt

I suppose you should first try to find the optimal settings based on the tips above, then try this version to see if it improves anything. Please also attach debug logs from a few seconds of playtest with this version on Win 7. Win 10 testing with this can be skipped until I've seen the original debug logs from that.

[Ombret4c]

thank you very much for all this, I will try to carry out the tests very soon!

I must specify that the pc currently under Windows 7 (amd hd 6550d is an APU so cpu+cgu together). This pc, under Windows 7 (and Windows 10 in the paste) makes the game work perfectly. on the other hand if I put the ddraw.dll then the game becomes very slow. the pilots are up to date, the APU is really old now.

my other pc which is much more recent is an intel i5 but I do not have the graphic part in mind, I will try to give it to you quickly. on the recent pc (windows 10), the game is unusable with or without ddraw.dll, the drawing is too high compared to my old pc (apu amd).

on windows 7 and windows 10 (old pc amd), I always set the desktop display (graphical interface) to a minimum with the least visual effect.

the screen display is standard and I have no "other" software that could interfere with the official panel of the graphics part.

what I have seen with the other players, they tell me all have a very fluid game when the pc is "old" or recent with windows 7. they tell me all feel slowness more or less important with windows 10 + recent pc

the game uses this graphics engine since 1999 to be exact, it has never evolved

[Ombret4c]

I send you the new ddraw.log that I can generate with the release available in our conversation. ddraw.zip

this log is produced with my old PC (windows 7). I will send you very soon the log with the new PC (windows 10).

I tested the normal ddraw.dll on the PC where the game is fluid (windows 7), with the dll the game becomes slow. 30ms drawing

[Ombret4c]

ok i have good news, on my recent pc (windows 10, i5 + geforce gtx 950m), the game is very fluid with your last dll (of our discussion), 7-8ms drawing, like on my old pc windows 7 !

I'm going to modify the gonconfig.exe to add a checkbox that will tell the gon.exe whether or not to use the ddraw.dll

do you think there is no problem to use the ddraw.dll (release) of our discussion you sent me on August 13th? otherwise I expect an official release from you, but it's amazing how fluid the game is thanks to you!

thanks to you, the players will be able to wait for october / november that I release the client with opengl

a thousand thanks you !

[Ombret4c]

ddraw.log with your ddraw_log.dll on my new PC windows 10: ddraw.zip

[narzoul]

Sure, you can use that release, although it's known to have some issues that won't make it work so well with other games (like 256 color modes not working). It's probably okay for this game.

Are you still interested in debugging the issue on your Windows 7 system? This test release you are now using for Win 10 has some additional debug logs, it would be useful to see a new log file taken with that on Win 7.

It's nice that it works well now on Windows 10, but for an "official" release it would be better to have a version that fixes the performance issue on both systems.

[Ombret4c]

that would be the ideal you're right

here is the new log (windows7) with the new ddraw: ddraw.zip

[Ombret4c]

a friend reports me that on his PC "Shadow" (windows 10 xeon), the game is fluid without dll, but with the dll the game reacted like on my windows 7! in fact it looks like if the game works well without dll, and we put the dll, then the game becomes slow.

[narzoul]

Is that the case with both the test release here and the "official" experimental release?

Also: were there any versions of DDrawCompat that had good performance for you on Windows 7?

[Ombret4c]

Negative performance when put the dll while the game was already fluid is indeed obtained with the real version and version of our discussion

I think I have already tested one versions DDrawCompat that had no negative effect on my windows 7 (and no positive effect because no problem)

tomorrow I will try to find the version that produced "no effect". I had fallen on it by testing a lot of dll for my windows 10 which had a slow game. I always tested the dll on my two pc.

[narzoul]

Well, I now realize my earlier analysis may have been partially incorrect, at least for points 1 and 2. The game doesn't really rely on video to system memory blits, and neither does DDrawCompat in this case. It does use blits from system to video memory, which is slow... but the only part of it that's really slow is a pfnLockCb call on a system memory surface, which is supposed to be almost instantaneous. This also seems to be the main cause of the slowness in the color conversion blit.

In the latest experimental release, that system memory surface is created by DDrawCompat directly from the user-mode display driver hooks, and I have not yet implemented any of the callback functions for that because I thought those are not used for system memory surfaces anyway (at least neither of my graphics drivers use them). But on your Windows 7 system, they are apparently used, and locking those allocations is always very slow. The two are hopefully related, and once I implement these callbacks properly, this issue may be gone.

Until then, I'll reupload the previous experimental version here, which did not have this problem. Please check the performance with the Release build in this on both of your systems, and if you can, ask your friend to test it too. Also, please upload a log from this version on Windows 7 with the ReleaseWithDebugLogs build. Thanks in advance for your continued support in troubleshooting these issues!

ddraw-debug.zip (commit 9b24a9b)

[Ombret4c]

my friend and I were able to make the new logs :)

Shadow xeon windows 10: ddraw_pc_shadow_win10.zip

Classic PC windows 7: ddraw_pc_classic_win7.zip

[narzoul]

I don't see anything wrong with the Win 10 logs. Were there any performance issues? I'd be more interested in the logs from the build that had poor performance on that system (the first custom build I attached here).

In your Win 7 logs, it looks like the only problem is the D3DKMTPresent call blocking for a long time. I have some ideas about that, let's see if I can fix that first.

[narzoul]

Here's another test release based on commit 9b24a9b: ddraw-debug.zip ddraw-debug-nopresentationwindow-diff.txt

This is an attempt to see if the long D3DKMTPresent time is caused by presenting to a WS_EX_LAYERED style window. This is only for testing on Windows 7. It should not make a difference on Windows 10. Please let me know what is the drawing time with this, and also attach the debug logs. Thanks!

[Ombret4c]

so in this post i will talk only about two tests done on the windows 7 with the latest ddraw-debug.zip

the release version of ddraw.dll allowed me to play with a fluid game, as if I had not put the dll, yet the drawing was high, 25-30ms, then suddenly the game became very slow , 10 seconds after

here is the log obtained with the special ddraw LOG: ddraw.zip

[narzoul]

This actually does fix the slowness in D3DKMTPresent, now it's pretty much instantaneous. I also added an extra log to this version to show whether desktop composition is enabled or disabled before each frame is presented to the window, and according to your logs, desktop composition is disabled on your system. I suspect that with desktop composition enabled, at least this part of the the issue should not happen. Could you please confirm that?

Here's a guide to enable desktop composition: https://www.trishtech.com/2013/10/enable-desktop-composition-in-windows/

Once you do that, you can confirm if desktop composition is enabled by taking new logs with this latest version and check a couple of the lines that say "DwmIsCompositionEnabled" (maybe one near the beginning of the log, one around the middle, and one at the end). If all of them read "DwmIsCompositionEnabled: 1 (0x0)" then composition should be enabled correctly, otherwise the lines will be "DwmIsCompositionEnabled: 0 (0x0)".

Once you have confirmed that composition was enabled successfully, please take new debug logs with the previous "ddraw-debug.zip (commit 9b24a9b)" version (the one I uploaded yesterday as a reupload of the previous "official" experimental release). Then you can either send these logs to me, or once again you can check them yourself: see the lines that have "D3DKMTPresent" in them. They should always be in pairs, and the time difference between the first and second line of each pair should be just 0 or 1 ms. If it's higher than that (8-16ms), then probably desktop composition didn't help.

I will try to figure out an adequate solution to this problem based on these results. Unfortunately the last one I uploaded can break the "GDI interworking" feature of DDrawCompat in many other windowed games and applications.

[Ombret4c]

DwmIsCompositionEnabled: 1 (0x0): ddraw_9b24a9b.zip

the performance remains very degraded with the dll, even if I activated the composition :(

[narzoul]

I can see that composition was enabled, but that is not the log I'm interested in it. After enabling composition, please use this version for testing:

ddraw-debug.zip (commit 9b24a9b)

Or did you use also test this version after enabling composition and checked the D3DKMTPresent logs manually? If not, please upload these logs, even if all performance issues are not solved.

[Ombret4c]

ddraw_with_composition.zip

ddraw_without_composition.zip

[narzoul]

Thanks for the logs! It confirms my suspicion: the D3DKMTPresent issue only happens when composition is disabled. I can't think of a proper workaround for that that doesn't cause other problems, so I'd suggest keeping desktop composition enabled, if possible.

I'm not sure why performance decreases over time. Maybe it's some kind of resource leak in DDrawCompat. Does the latest official experimental build also have this problem?

Anyway, I can't see any other obvious performance issues from the logs when composition is enabled, so hopefully once I fix the callbacks in the official experimental build, the remaining performance problems will be solved as well, at least for Windows 7. I'll still need to investigate the problems with Windows 10 further afterwards.

[Ombret4c]

on a pc that has no problem with the game, having the composition or not is not a solution to the problem of loss of performance when using the ddraw.dll

for me it does not matter the current version, if the game is fluid naturally, but we put the dll, then the game is no longer fluid

in my personal case everything is perfect, because my windows 7 has never had a problem with the game, it has always been 7-8ms. only my recent pc windows 10 has a slow game, 70ms. now is 7-8ms too with the ddraw.dll :)

I am looking forward to testing your future versions, for now I explained to the players to use the ddraw.dll only if the drawing is above 15ms. this makes it possible not to offer the ddraw.dll to players who do not have a problem, as this will result in performance degradation.

thank you again for your work, a lot of players were able to find a fluid game thanks to you!

[narzoul]

After checking your logs again, I noticed that none of the surface allocations are tied to resources, which means implementing the callbacks I mentioned earlier might not make any difference. I've made a small change that should crash the application if the callbacks are really needed.

I had another idea that maybe the slow locks are somehow related to how the surface system memory is allocated. I made another change so that the memory allocation method is now similar to what native DirectDraw uses.

Please test this version on all 3 systems if possible (or just the ones you can), and let me know the drawing times (with the Release build) and attach debug logs if you can. If none of the above changes make any difference, then I'm out of ideas for now...

ddraw-debug-8cc73dc-localalloc.zip ddraw-debug-8cc73dc-localalloc-diff.txt

[Ombret4c]

I could only test on the windows 7 which has the fluid game without dll

here is the log ddraw.zip

with the dll the game gets slower, 20-30ms drawing instead of 7-8.

[narzoul]

Thank you. Unfortunately, that didn't seem to make any difference. I have one more idea to try...

ddraw-debug-8cc73dc-localalloc-prelock.zip ddraw-debug-8cc73dc-localalloc-prelock-diff.txt

Please test this also and attach the debug logs. Win 7 only is fine.

[Ombret4c]

the problem remains the same (windows 7). you lost enough time for me lol

here are the logs ddraw.zip

[narzoul]

After comparing your logs with mine (both using AMD drivers), I noticed a possible similarity. Both of them seem to use an alternative code path for blits from system memory to video memory when the system memory buffer is 32-byte aligned, which is true for the allocations I create in the latest version, but not for most native DirectDraw allocations (which are offset by 8 bytes for some reason, breaking the alignment).

This code path is significantly slower on your system than mine (maybe a driver bug?), but at least I can work around it. With the below patch I can no longer see traces of the "slow" code path in my logs. Hopefully your driver will behave similarly, and this should fix at least one of the performance problems. Please try it on Windows 7.

ddraw-debug-8cc73dc-misaligned-alloc.zip ddraw-debug-8cc73dc-misaligned-alloc-diff.txt

By the way, in your last logs I noticed desktop composition was probably disabled again. Please enable it for the duration of the tests, at least.

[Ombret4c]

ok its better (windows 7) !

without dll : 8ms release dll without composition : 15ms (some slowness are noticeable) release dll with composition : 8ms !!

without composition : ddraw_without_composition.zip

with composition : ddraw_with_composition.zip

[Ombret4c]

some player with windows 10 report that the game opens and closes 2-3s later, when they use the dll (the first ddraw.dll that produced good performance drawing)

for now I have not shared any other ddraw.dll

[narzoul]

Which version are you referring to exactly? The one that I just attached here (ddraw-debug-8cc73dc-misaligned-alloc)? Please send me the debug logs from the crashes, if possible.

[Ombret4c]

no I'm talking about the first version that worked, I did not share the other versions of our discussion

this version https://github.com/narzoul/DDrawCompat/issues/47#issuecomment-520612553

but I did not have the opportunity to suggest to the players to make logs with the ddraw.dll which log I will try to organize this with some players, for the moment I referenced 3, all on windows 10

[narzoul]

About disabled composition: I have one last idea to try before giving up on this. If this doesn't work, I'll probably just put a note in the readme somewhere that it's not supported. It's not feasible to develop support for it when I can't test it. Please check this version for one last try:

ddraw-debug-8cc73dc-misaligned-alloc-nocomposition.zip ddraw-debug-8cc73dc-misaligned-alloc-nocomposition-diff.txt

I won't need the logs, just check the performance and whether it displays correctly. On my system it has the same performance as the composition enabled branch, but there is noticeable stuttering when moving around. However, that may just be because I can't really disable composition, I could only "fake" it and test the code branch that executes when it's disabled.

After this, I think it's time to move on to the Windows 10 issues, no matter the outcome.

[Ombret4c]

no change indeed, I stay at 15ms drawing, with delays (composition disabled)

I will try to contact a player to provide me with a game log that closes with the dll I shared

[Ombret4c]

ok I can get it now :)

Log: ddraw.zip

[narzoul]

I found the problem. The user has DPI scaling set to 125% and the process executable is not marked as DPI-aware, which causes a difference in the display resolution and desktop resolution. I will add a fix to DDrawCompat later. Meanwhile, it can also be fixed by right-clicking on gon.exe, and then Properties -> Compatibility -> Change high DPI settings -> Override high DPI scaling behaviour, Scaling performed by: Application.

[Ombret4c]

great thank you very much, a player will test this in the evening. I will come to give you the result here :)

[Ombret4c]

the player windows 10 (pc Shadow with Intel XEON), which had slowness only when he put the dll, has no more problem this dll ddraw.zip

this is one of the last you asked me to test, I do not know exactly which version ..

I think it's the version that works on my windows 7 with the composition

with this dll he has 3-4ms drawing (7ms without the dll)

for now I have not had the return of the player with the dpi setting and the game that closed, I wait.

[narzoul]

Nice! It is this version: ddraw-debug-8cc73dc-misaligned-alloc.zip

Could you test this on your own Windows 10 system too, please? If it still has performance problems, please attach the logs. I wonder what exactly was fixed by using textures instead of off-screen plain surfaces in my initial version that fixed the performance issues for you on Win 10. Or maybe that fix is not needed anymore at all?

[Ombret4c]

I tested the pc of a player with teamviewer, it does not have the option of the dpi in the> compatibility of gon.exe (windows 10)

I will soon test this dll on my windows 10, I think it will produce the same performance gain as the old, around 7ms

[Ombret4c]

I was able to test the dll on my windows 10, it is always fluid :)