Mig Alley Windows 10 Error

[TheSilkMan]

Hi Narzoul, it appears the v0.3.1 dll breaks Mig Alley. The dll from v0.2.1 still works. So, somewhere between the two versions a change has caused this. The following error occurs: "The procedure entry point SymAddrIncludeInlineTrace could not be located in the dynamic link library C:\Windows\System32\dbeng.dll."

The log file reads: 4300 23:36:49.449 Process path: C:\migalley\MigAlley.exe 4300 23:36:49.449 Loading DDrawCompat from C:\migalley\DDRAW.dll 4300 23:36:49.451 DDrawCompat loaded successfully 4300 23:36:50.136 Installing DirectDraw hooks 4300 23:36:51.397 Installing GDI hooks 4300 23:36:51.408 Installing registry hooks 4300 23:36:51.408 Finished installing hooks 4300 23:40:22.485 GDI used DC cache size: 1

[narzoul]

If there's a dbghelp.dll file in your install directory, rename it or remove it. Some games ship with an old version of the file, but Windows has a much more recent version already, and the old version is incompatible with the newer dbgeng.dll in Windows. I will add a workaround to the next release that may help with this (force load the Windows version of dbghelp if possible).

[TheSilkMan]

Thanks. I did see that file there and will try removing it from the game directory. Great job removing that black box off of the screen. How did you find and accomplish that? One other thing that happens is sometime when exiting 3d from a mission, the game hangs. When I alt tab, I see the game window with the black box, but it fails to exit to the 2D map. Have to use taskmaster to force it to close.

Finally, have you found a way to fix the patchy holes in the cockpit textures of the F-86?

On Sat, Oct 2, 2021, 3:37 AM narzoul @.***> wrote:

If there's a dbghelp.dll file in your install directory, rename it or remove it. Some games ship with an old version of the file, but Windows has a much more recent version already, and the old version is incompatible with the newer dbgeng.dll in Windows. I will add a workaround to the next release that may help with this (force load the Windows version of dbghelp if possible).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/narzoul/DDrawCompat/issues/116#issuecomment-932702177, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ3ND3QJWWFSWPUEMIJNLLUE2ZEJANCNFSM5FF5NQCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[TheSilkMan]

Hi Narzoul, I removed the dgbhelp.dll file. The error no longer appears at launch of the game. However, with the new ddraw.dll the game starts to launch, then goes directly back to desktop. No events are recorded in the log file. The old ddraw.dll still works though.

On Sat, Oct 2, 2021, 11:57 AM garyjnj1 @.***> wrote:

Thanks. I did see that file there and will try removing it from the game directory. Great job removing that black box off of the screen. How did you find and accomplish that? One other thing that happens is sometime when exiting 3d from a mission, the game hangs. When I alt tab, I see the game window with the black box, but it fails to exit to the 2D map. Have to use taskmaster to force it to close.

Finally, have you found a way to fix the patchy holes in the cockpit textures of the F-86?

On Sat, Oct 2, 2021, 3:37 AM narzoul @.***> wrote:

If there's a dbghelp.dll file in your install directory, rename it or remove it. Some games ship with an old version of the file, but Windows has a much more recent version already, and the old version is incompatible with the newer dbgeng.dll in Windows. I will add a workaround to the next release that may help with this (force load the Windows version of dbghelp if possible).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/narzoul/DDrawCompat/issues/116#issuecomment-932702177, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ3ND3QJWWFSWPUEMIJNLLUE2ZEJANCNFSM5FF5NQCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[narzoul]

I haven't done anything about a "black box" because it was never there with DDrawCompat. Isn't it just an issue with other wrappers? I still don't have an NVIDIA test system, so I can't do much about the cockpit issues. It doesn't happen on AMD or Intel. I asked for debug logs from an NVIDIA system a long time ago on Vogons, but never got them. I'm not sure it would be enough to figure out the problem anyway.

As for v0.3.1, do you mean there is no DDrawCompat-MigAlley.log file at all? Note that the log file name changed since v0.2.1.

[TheSilkMan]

Hi Narzoul, yes the black box occurs when you run the game on Windows 10 without any wrapper or with wrappers other DDrawCompat. With DDrawCompat, the box (which is designed to house the ui and swap z-order with 3d window when in 3d)still occurs as with other dual windows games, but correctly resizes and gets placed in correct Z-Order beneath the 3D window.

Yes, I am running an NVidia 3070 card. The missing cockpit texture pieces also occurred in my older 980ti card. If you tell me how to generate the NVidia debug file(and where it saves to), I'll be sure to share it with you.

I double checked the log file. It is being generated under the name DDrawCompat-MigAlley.log in v0.3.1(contents in the attached). In this version, the game never fully loads to the main UI. It immediately drops to desktop. It is 100% repeatable and as such, the game is unplayable.

In v0.2.1, when playing a campaign, after flying a mission, exiting and the game attempts to return you to the 2D map screen, the game hangs and never loads the 2d map. This only happens with the DDrawCompat wrapper. It is 100% repeatable. It also happens periodically when exiting 3D and returning to 2D map in the HotShot quick mission. I have not seen this with other wrappers.

On Sun, Oct 3, 2021, 5:21 AM narzoul @.***> wrote:

I haven't done anything about a "black box" because it was never there with DDrawCompat. Isn't it just an issue with other wrappers? I still don't have an NVIDIA test system, so I can't do much about the cockpit issues. It doesn't happen on AMD or Intel. I asked for debug logs from an NVIDIA system a long time ago on Vogons, but never got them. I'm not sure it would be enough to figure out the problem anyway.

As for v0.3.1, do you mean there is no DDrawCompat-MigAlley.log file at all? Note that the log file name changed since v0.2.1.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/narzoul/DDrawCompat/issues/116#issuecomment-932895911, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ3ND6OK5CE5OAK6DBRCT3UFAN73ANCNFSM5FF5NQCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. ⁸

[narzoul]

I don't see any attachments. Maybe it doesn't work if you send it as an e-mail attachment. Try attaching it via GitHub.

v0.2.1 is more than 5 years old. The hanging issue has probably been fixed already. At least I haven't encountered it while testing this game recently.

[TheSilkMan]

Hi Narzoul, thanks for the reply. Sounds good, I am hoping to get v0.3.1 working to see your progress. Attached is a screen shot of the log file.

[narzoul]

Nothing unusual there so far. Please try collecting the logs using the ddraw.dll from the ReleaseWithDebugLogs build found in the debug release: https://github.com/narzoul/DDrawCompat/releases/download/v0.3.1/DDrawCompat-v0.3.1-debug.zip

Also, if it's a crash, you might be able to get a crash dump following the instructions here: https://github.com/narzoul/DDrawCompat/issues/50#issuecomment-520162844

Please attach both (preferably in a zip archive) if possible.

On a side note, why is your executable called MigAlley.exe instead of just Mig.exe? What patches have you installed?

Although I doubt it's related, Win98 compatibility mode should not be needed. You can use Windows 8 compatibility mode if the thick window borders in the game UI bother you, otherwise no compatibility mode should be set.

[TheSilkMan]

Hi Narzoul, I will give this a shot tonight. Also, how do I obtain the Nvidia specific report that you need?

In terms of the file and directory naming convention. I prefer to call things what they are(hence MigAlley). The sim is about much more than just the Mig. ;)

On Mon, Oct 4, 2021, 6:16 AM narzoul @.***> wrote:

Nothing unusual there so far. Please try collecting the logs using the ddraw.dll from the ReleaseWithDebugLogs build found in the debug release:

https://github.com/narzoul/DDrawCompat/releases/download/v0.3.1/DDrawCompat-v0.3.1-debug.zip

Also, if it's a crash, you might be able to get a crash dump following the instructions here:

50 (comment)

https://github.com/narzoul/DDrawCompat/issues/50#issuecomment-520162844

Please attached both (preferably in a zip archive) if possible.

On a side note, why is your executable called MigAlley.exe instead of just Mig.exe? What patches have you installed?

Although I doubt it's related, Win98 compatibility mode should not be needed. You can use Windows 8 compatibility mode if the thick window borders in the game UI bother you, otherwise no compatibility mode should be set.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/narzoul/DDrawCompat/issues/116#issuecomment-933342829, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ3ND5GGJHGKS633S6NBJTUFF5IVANCNFSM5FF5NQCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[narzoul]

It would need the logs from the ReleaseWithDebugLogs build also, but that comes only after getting v0.3.1. working. Just run it with that build in a quick mission for a few seconds and then exit and collect the logs.

[TheSilkMan]

Hi Narzoul, since it crashes immediately upon launch, I never get to go into quick mission wth v0.3.1. However, I was able to grab todays crash log and the dump file(see attached Silk's Mig CrashLog.20904.zip ).

[narzoul]

Thanks! So it crashes directly after enumerating all display modes, while passing back the last result to the application (which is simply that there are no more display modes to enumerate). You have 336 natively supported display modes on your system, which DDrawCompat triples by adding 8/16 color depth modes for each of them, making a total of 1008 display modes. My guess is that Mig Alley is not prepared to handle such a huge list.

I'm a bit puzzled as to why it works with v0.2.1 though. The 8/16 bit color depth enumeration wasn't added to DDrawCompat back then, but the Windows compatibility shims should have added them anyway. Otherwise you wouldn't have been able to start any missions (I checked and it throws an error message if only 32 bit color depths are enumerated). Maybe it's all just luck: the memory layout happened to be different with v0.2.1, so some buffer overflow didn't cause a crash.

Anyway, to verify this theory, I removed the enumeration of 8 and 32 bit display modes from v0.3.1 in this test version: ddraw.zip (diff.txt compared to v0.3.1)

The game only seems to require 16 bit modes anyway, so this still works on my end. Let's see if it fixes the crash for you.

[TheSilkMan]

Hi Narzoul, that worked! It now loads correctly to the menu and no CTD. Another good thing is that after exiting campaign missions no longer cause as freeze/lockup as in v0.2.1. Even better, frame rates are very high both in campaign and quick mission. Another good thing is that the load screen graphic is much bigger and fills most of the screen. Before it did not enlarge and just stayed very small. Log file: DDrawCompat-MigAlley.log

There is however one show stopping anomaly. It now takes up to 7 minutes from launch of either a quick mission or campaign mission to load the 3d world. Perhaps, you included the the debug version of the dll? Running in debug normally causes that type of delay.

The other thing I noticed is that on load with this version, it causes that 2nd window for the UI to not follow Z-order and be hidden during the loading of the 3d world(visible with the load screen). This did not happen in v0.2.1. It resolves itself after load. I have a 3 monitor setup so perhaps this is why I see it(on the 2nd monitor).This did not happen in v0.2.1. It resolves itself after load. There is a little lag or menu trailing when you grab a menu and drag it to relocate it to another part of the desktop. No thick borders though.

[TheSilkMan]

After that, just need to resolve the Nvidia missing cockpit texture issue.

One feature that would be nice is to be able to fill the three monitors with the full world, (i.e., maintain the aspect ratio without getting the distortion that can come with just stretching of the view).

[narzoul]

The attachment was a release version. But from the symptoms, it sounds a lot like an old issue that was discussed here when trying to view 3D models by pressing the Photos button in campaigns: https://github.com/narzoul/DDrawCompat/issues/12#issuecomment-635207551

For Photos, it's a CPU scheduling issue, since DDrawCompat restricts execution to a single CPU core (to mitigate stability issues in many of these old games), and also disables the thread priority boost feature of Windows (for the current process), because it causes stuttering or other problems in some other games. These are usually caused by inefficient thread synchronization (e.g. polling) in the games themselves. For Mig Alley, it's one of the threads doing busy waiting during loading, which chokes other important threads when priority boosting is disabled.

Here's a test version that re-enables thread priority boosts: ddraw.zip (diff.txt compared to v0.3.1) It works for the issue with Photos, hopefully it'll help with your long load times as well.

I don't fully understand the Z-order issue. Does it only happen in multiple monitor setups? I've noticed from your earlier debug logs that you have a strange desktop resolution of 11520x2160. I didn't know it can even get that high. Is that the resolution of a single monitor, or all 3 combined? If the latter, how did you achieve that? With NVIDIA Surround or some similar tool? What does it look like when the game goes full screen? (Note that the menus are in borderless windowed mode I think, only the 3D parts are full screen). Does it display on a single or multiple monitors? Multiple-monitor full-screen mode is not supported by DDrawCompat. I never bothered with it, because I figured no applications would actually support it anyway. If it interacts in some way with Eyefinity or Surround then I have no idea how that works.

The menu lag issues were also mentioned in that other thread. It's far from trivial to fix and also not at the top of my priority list, so it's unlikely to be improved any time soon.

Aspect correct widescreen mode would require a game specific widescreen patch. I don't think it can be done in a generic way from any DirectX wrapper.

[TheSilkMan]

Hi Narzoul, ok I was able to try it tonight. Load times are the same(or longer). However, this version also causes the load status bar to not appear.

Just for comparison, I loaded up the v0.2.1 again. I noticed that the 0.2.1 actually only uses the center monitor when in 3d loading and 3d world(left and right monitors go to monitors default screen[aka blue screen on some machines], hence why I didn't see the overlapping box. It appears in the far left monitor with the DDrawCompat dll. With the default code in Windows 10, it just stays and overlaps smack over the 3D world. Also, the Hotshot mission loads slowly like v0.3.1 and v0.3.1+, but loads much faster in Campaign. In v0.2.1 framerates are subpar when compared to v0.3.1+.

Yes you are correct, I have a triple monitor setup. It is running in Nvidia surround mode which causes windows to see all three monitors as one giant 11520x2160 monitor(i.e., 3 screens each have 3840x2160). The game supports 3 monitors. However, 3d and driver have to be optimized to fully take advantage of it. For now, a command line switch forcing it to load in the 11520x2160 can work. I was able to exploit this feature in DxWnd. The drawback was the somewhat stretched aspect angle. However, the game can be zoomed to somewhat correct for this using the built in wide screen zoom. Its not perfect but it will fill the three monitors. Right now, 2d uses all three screens, 3d uses center only.

More on the Overlapping Window

The code pushes the 2d swapped (UI Window) off out of view(upper leftmost corner of a virtual left screen) during 3D(win95, XP,Win7). Back then they assumed that people would not see it(out of sight out of mind). As such, it's not just a Z-Order issue as I thought. It would have been much better if it was just minimized when in 3d and maximized when in the UI.

[narzoul]

Load times are the same(or longer)

Please try it with all CPU cores enabled (from Task Manager, after launching the game).

With the default code in Windows 10, it just stays and overlaps smack over the 3D world.

The default mode for DirectDraw (since Vista probably) is an emulated borderless windowed mode (the application thinks it's running in exclusive full-screen mode, but it's actually windowed). So it might interact with window placement differently. Try it with the "DXPrimaryEmulation -DisableMaxWindowedMode" shim from ACT and see if there's a difference when it runs in real exclusive mode (like it does with DDrawCompat).

The game supports 3 monitors. However, 3d and driver have to be optimized to fully take advantage of it.

I don't understand what you mean by this. But if it only works via Surround, then I'm pretty sure the game itself only sees/uses one "virtual monitor" at a time, the same as if it was running on a single monitor. If it works without Surround too, then let me know how to set it up, I'll try to test it with 2 monitors.

[TheSilkMan]

Hi Narzoul. I will attempt to try ACT shims tonight. Never tried the all cores setting in taskmanager, from the list of open programs where would I find the all cores setting?

In terms of number of monitors, Mig searches for the number of actual monitors reported by directx and uses that. It then sets up where to place the ui. Since the code was written b4 any other technologies like Nvidia surround and eyefinity, it relies solely on dx enumerations. So, even though surround is turned on via the Nvidia driver, the game uses the default dx reporting. It seems to ignore the Nvidia surround driver settings. With 2 or more monitors, you should see a bigger map( across the available monitors) and ui will be placed in the monitor designated as the primary. In 3d, it places the 3d in that same monitor ( or center most monitor in a 3 monitor setup) and ignores(blacks out or does not send input to) the additional monitors. At some point I would like to have the 3D behave just like the 2D map and show more of the 3d world on the right and left monitors.

[narzoul]

Ok, I tried it out with 2 monitors, with and without Eyefinity, and it pretty much behaves as I expected. Note that the game only uses exclusive full screen mode for the 3D parts. All 2D stuff like the menus and campaign screen are in windowed mode in a maximized borderless window.. That said, there is still no sign of any particular multi-monitor support implemented directly by the game.

Without Eyefinity, everything is displayed on a single monitor, for the most part. The main menu and campaign screen happen to go on my secondary (right side) monitor, although the campaign exit confirmation box shows up centered on the primary. Other than that, the primary monitor just shows the desktop the whole time. When entering 3D, everything switches to the primary monitor, and the secondary shows the desktop instead. Interestingly, when exiting 3D, the main menu window switches to the primary monitor too, and stays there. Then the secondary monitor shows the desktop. Rather flimsy, but not unexpected of an app not really supporting multiple monitors.

In Eyefinity mode, the menu and campaign screens cover both monitors. The main menu is centered, with large black bars on the left and right side (same as in single monitor mode, but with larger bars). This actually splits the menu itself in half between the two monitors. The campaign screen uses the entire window (same as in single monitor mode, but there's a lot more space with 2 monitors combined into one). In the 3D parts, exclusive full screen mode in my case is handled by showing the same 1024x768 resolution image cloned to both monitors, but with different scaling modes (centered vs stretched), which might just be how the monitor/driver handles it.

So there's nothing really specifically designed to work with multiple monitors. It's just that in the windowed parts of the game, the campaign screen happens to use the full available area of the maximized window, which fills both monitors if Eyefinity/Surround mode is used. And full screen mode renders only to one primary screen as expected - how it's handled in Eyefinity/Surround mode is up to the driver implementation of those modes. It would require a lot of effort on the application's part to handle real multi-monitor rendering, as explained in the DirectX 7 SDK. In windowed mode, you get automatic support for extended desktops, with some performance penalty on non-primary monitors, unless you specifically optimize for the multi-monitor case (this is explained in the SDK as well). No sign of that here either.

Never tried the all cores setting in taskmanager, from the list of open programs where would I find the all cores setting?

In the Details tab, right click on MigAlley.exe, select "Set Affinity" from the popup menu, tick the checkbox next to "\<All processors>" and click OK.

[TheSilkMan]

Thanks for review of the dx7 SDK. I believe you nailed what is happening. It would be nice to have that extended desktop implementation(3d world).

I tried that affinity setting and man(@!!) I have to say it runs like a cheetah! It loads so fast you don't even get to see the load bar. Nice work! I'm highly impressed. Only problem is that once you exit the game, you have go and reset affinity again. Is there a way to force it on at all times for the executable?

I also noticed that ALL of my monitor resolutions now appear in the resolution menu. Before, it populated with a partial list of resolutions.

[narzoul]

There will be a config option in the next release for CPU affinity (among other things). For now, you can use this test release, where I removed the single core affinity setting (in addition to the previous changes): ddraw.zip (diff.txt compared to v0.3.1)

Since this should work well enough now, I've included a ReleaseWithDebugLogs build also to check out the cockpit transparency issue. Just reproduce it on screen in some quick mission for a few seconds, exit the game and upload the logs (compressed).

[TheSilkMan]

Hi Narzoul, in both debug and non-debug versions, it loads in single core affinity mode. I verified this by checking the affinity of each. After the debug version finally loads and I exit, the log file is 89,155 kb and cannot be attached here.

The non debug versions loads fast as usual when affinity is set to all. When I set the affinity to all and load in the debug version(figured I'd give it a shot), it minimizes to the taskbar and no way to maximize the game to full screen.

[narzoul]

Are you still using Windows 98 compatibility mode? It forces single core affinity too. Disable it or switch it to Windows 8 to avoid the thick window borders in the campaign screen popups.

[TheSilkMan]

Yes, it was in compatibility mode. Unchecked that and it solved the problem. The affinity fix now works. Below is the log from debug version. I could not do much looking around with the views since the file gets really large. I basically entered 3D, then exited. The main cockpit texture in the F-86 is patchy with segments missing so it should show up in the log.

DDrawCompat-MigAlley.log

[narzoul]

Thanks! Looking at the logs, and some screenshots found online about the issue, it seems obvious that the transparent parts are where the original textures contain black pixels. The logs also tell that the D3DDDITSS_DISABLETEXTURECOLORKEY and D3DDDITSS_TEXTURECOLORKEYVAL texture stage states are never initialized by the Direct3D runtime, which is probably what causes different behavior on different drivers. NVIDIA seems to default to black pixels as transparent, while other drivers have disabled texture transparency by default.

I've made two slightly different patches (on top of the previous ones in this thread) in an attempt to fix the issue. The first one is less efficient but more likely to work. Please test both of them and let me know which one works: ddraw-1.zip (diff.txt compared to v0.3.1) ddraw-2.zip (diff.txt compared to v0.3.1)

[TheSilkMan]

"NVIDIA seems to default to black pixels as transparent." I wonder why they chose to do this. Ok, I tried both and so far, no difference in the the transparent pixels. I also tried turning transparency on and off and the various filter options in the game but that doesn't seem to help.

Changing from primary(NVidia) driver to software driver stops the transparency issue, but (of course) you lose all Directx 3d effects.

[narzoul]

Strange that neither fix has any effect at all. I can reproduce the problem on my AMD GPU by forcing black to be the transparent color, instead of disabling color key transparency.

Well, that gives me another idea. Instead of trying to disable the transparency, let's see if we can change the transparent color to white instead: ddraw.zip (diff.txt compared to v0.3.1)

On my system, this makes only a few pixels (small rectangles) transparent on the top light-gray part of the cockpit. I hope it will have a similar effect for you, meanwhile fixing the black parts.

[TheSilkMan]

Hi Narzoul, you are definitely on to something. This eliminates the missing black textures. However, I do see the missing grey pieces on the range meter, the star on the wings, and the text in the exhaust temperature guage reverts to black(instead of white).

[narzoul]

Ok. Let's have one more test for today please, just to confirm my theory. So it seems the "disabling" color key transparency for textures means setting black as the color key for NVIDIA.

Here's a modified version of the previous patch: ddraw.zip (diff.txt compared to v0.3.1)

After setting the color key to white, it immediately sets is back to disabled. Now it renders perfectly on my system, but I assume it's going to just revert back to having black as the transparent color on yours. If that's the case, I'm gonna have to come up with some creative workaround to fix this driver bug efficiently...

[TheSilkMan]

Hi Narzoul, it's pretty much the same on my end:

[narzoul]

So in summary, the following bugs are present in NVIDIA drivers:

• Texture color key defaults to black instead of disabled
• D3DDDITSS_DISABLETEXTURECOLORKEY has no effect

I've looked into the docs, and there is one more way to disable texture color keying, by setting the D3DDDIRS_COLORKEYENABLE render state to false. In fact, it's supposed to be false by default, and the game makes no attempt to change it. But as it turns out, this render state was introduced in DirectX 5, and it used to be enabled before that by default on hardware devices.

It seems that newer DirectX versions try to stay backwards compatible by detecting which Direct3D interface version is used, and setting the default value to true or false based on that. Even though Mig Alley comes with DirectX 6, it uses much older Direct3D interfaces for rendering. So the default value is true, while in a game like Unreal, it can be seen that the default is set to false.

Here's another fix attempt by forcing COLORKEYENABLE to false: ddraw.zip (diff.txt compared to v0.3.1)

It's not a good generic solution, but it should work for Mig Alley, since it doesn't seem to use texture color keying anyway (except for palettized textures, based on the game's source code, but that's not supported/used on modern hardware anyway).

[TheSilkMan]

Ok. Just tried it. It works 100%!

Thanks Narzoul, for diving even deeper into what was going on and resolving the driver issue. I can't thank you enough.

[narzoul]

The NVIDIA texture color key issues should be solved in v0.4.0.

[TheSilkMan]

Thanks a lot Narzoul. I will check it out.

On Tue, Sep 27, 2022, 5:01 PM narzoul @.***> wrote:

Closed #116 https://github.com/narzoul/DDrawCompat/issues/116 as completed.

— Reply to this email directly, view it on GitHub https://github.com/narzoul/DDrawCompat/issues/116#event-7472190356, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ3ND2CLIWVGM2ESPGBAI3WANOBHANCNFSM5FF5NQCQ . You are receiving this because you authored the thread.Message ID: @.***>

[TheSilkMan]

Hi Narzoul, what other changes or features does 4.0 bring vs 3.1? For instance, does it still feature the CPU Affinity fix?

On Tue, Sep 27, 2022, 8:44 PM garyjnj1 @.***> wrote:

Thanks a lot Narzoul. I will check it out.

On Tue, Sep 27, 2022, 5:01 PM narzoul @.***> wrote:

Closed #116 https://github.com/narzoul/DDrawCompat/issues/116 as completed.

— Reply to this email directly, view it on GitHub https://github.com/narzoul/DDrawCompat/issues/116#event-7472190356, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ3ND2CLIWVGM2ESPGBAI3WANOBHANCNFSM5FF5NQCQ . You are receiving this because you authored the thread.Message ID: @.***>

[narzoul]

There is a setting for it. Read the release notes.

[TheSilkMan]

Hi Narzoul, I tried v4 with Mig Alley. Unfortunately it CTDs after double clicking the icon. Log says files are missing

On Thu, Sep 29, 2022, 2:28 AM narzoul @.***> wrote:

There is a setting for it. Read the release notes https://github.com/narzoul/DDrawCompat/releases/tag/v0.4.0.

— Reply to this email directly, view it on GitHub https://github.com/narzoul/DDrawCompat/issues/116#issuecomment-1261825456, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ3ND6VB2NRIB6QL32D7NTWAUZKVANCNFSM5FF5NQCQ . You are receiving this because you authored the thread.Message ID: @.***>

[narzoul]

From reading back the discussion here, the game crashed for you with v0.3.1 also without some custom modifications, due to too many supported display modes. You can probably do those modifications now via config files. Check the Configuration wiki for details.

Based on the previous discussion, I'd suggest the following settings: CpuAffinity=all SupportedResolutions=640x480, 800x600, 1024x768 ThreadPriorityBoost=on

Just put them in a DDrawCompat.ini file in your game directory.

[thomasplummer55]

Hi Narzoul,

I have followed this discussion with interest since I have been trying to run Mig Alley on Win10. I have now had good success with one of your ddraw.dll files and a standard BDG install of Mig Alley. Framerate is 60 everywhere and no CTDs or artifacts. The specific ddraw.dll is the one referenced in this discussion with this text:

"Anyway, to verify this theory, I removed the enumeration of 8 and 32 bit display modes from v0.3.1 in this test version: ddraw.zip (diff.txt compared to v0.3.1)"

These show my system and graphics driver:

I dragged and dropped the pictures here but I just see encoded text, is there another way??

Thanks for your work on Mig Alley, I can say that it runs better than Win98 or WinXP which are 50 fps. I can now fly on Win10 without the need to use my WinXP laptop.

Well done Narzoul, Thomas