Might & Magic Compatibility Layer (Tool)

[Emjayen]

I've written this tool [MMCL] to provide better compatibility for Might & Magic 6, 7 and 8 with modern kernels by emulating the old DirectX APIs the game uses, solving a few common issues (e.g, "flickering", performance, ect) and better compatibility with tools such as screen-capture software and video card vendor (e.g, Nvidia) tools.

Additionally,included is preliminary support for enabling arbitrary display resolutions (screenshot: http://i.imgur.com/ikK8BTg.png -- 1680x1050, note that the UI overlay is simply scaled)

Be aware that that is an alpha release and so there are still quite a few bugs (particularly with non-native game resolutions). That being said, I'd appreciate it if you report any bugs/issues you discover, including the following information in your post:

• Your OS version (e.g, "Windows 8")
• Your log file ("mmcl.log")
• Your crash-dump (if the game crashed)
• A screen-shot (if relevant)
• Any other relevant information.

Download

http://laserblue.org/mmcl.zip (0.0.0.3/Alpha)

To install:

• Extract/copy ddraw.dll and mmcl.ini to your installation folder (it should be alongside mm7.exe and the like)

There's a few settings you can configure via mmcl.ini

Notes

• Requires Windows Vista or later
• MMCL does not work with the game's "windowed" mode, however you can achieve the same effect by enabling "Windowed" in mmcl.ini
• Tested against 1.1 (filever: 1.0.0.1) and GrayFace (filever: 1.2.1.0) binaries.
• A small bug in the engine's UI rendering at larger resolutions has unfortunately required patching the game itself (this is done only at runtime, thus not persistent)
• Disable any compatibility-mode settings
• No custom resolution support for MM8 or MM6 (latter will be supported in release)

Known Issues

• [MM7/8] Game mouse-input does not work at all when using non-game-native (ie., not 640x480) resolutions -- UI input not affected.
• [MM7/8] Cursor behaviour/performance issues.
• [MM7/8] Incorrect rendering of monsters info. display when right-clicking
• [MM7/8] Rendering issues with software 3D mode ("Software" in the setup utility)
• [MM7] Breaks GrayFace patch's "MouseLook" feature.
• [MM7] Breaks GrayFace's "MMExtension"

[Emjayen]

0.0.0.2/Alpha (21-5-2017)
=========================
- Added support for Might & Magic VI
- Added support for Might & Magic VIII

[tomchen1989]

Sounds really great. Unfortunately it doesn't work for me.

Windows 10. Crash dump and other files are here:
https://www.dropbox.com/s/y6nfgu4gh65j6 ... s.zip?dl=0

[Emjayen]

Sounds really great. Unfortunately it doesn't work for me.

Windows 10. Crash dump and other files are here:
https://www.dropbox.com/s/y6nfgu4gh65j6 ... s.zip?dl=0

Thanks for the detailed report.

It appears you have a compatibility-mode enabled; try disabling it.

[GrayFace]

Cool! I'm surprised how much better everything actually looks in good resolution. I didn't notice problems with filtering. It's going to be great when it's done.
In any resolution it's incompatible with mouse look in my patch, also mouse moves like it's on drugs - I do a move and then the cursor catches up in a very short, but noticeable time. Why do you have to change how mouse works at all? Because of DirectInput? If yes, then a version that only does graphics would be handy.
Also incompatible with MMExtension, I can look into that.

[Emjayen]

Cool! I'm surprised how much better everything actually looks in good resolution. I didn't notice problems with filtering. It's going to be great when it's done.

Yeah, I, too was surprised. Particularly at how well the UI turned out given it's simply bilinearly scaled -- point filtering may even give a decent result and intend to enable this to be configurable for users.

In any resolution it's incompatible with mouse look in my patch, also mouse moves like it's on drugs - I do a move and then the cursor catches up in a very short, but noticeable time. Why do you have to change how mouse works at all? Because of DirectInput? If yes, then a version that only does graphics would be handy.

I was able to reproduce that behaviour with Win95 compatibility mode enabled. I haven't looked into which actual associated aclayer fix causes it, but it results in the DInput thread only sampling at roughly 1Hz which in turn means the cursor is only updated at the same rate and sounds like what you're describing. That being said; try disabling any compatibility mode, if it still persists I'll have to look into it more.

The issues with mouse-look is another story -- although I do intend to [optionally] provide DInput emulation due to it being all but deprecated, at the moment MMCL does not interfere directly with the mouse at all and so I suspect the problem is related to the differing window/cursor handling behaviours of DirectDraw vs Direct3D9 (the game's window handle gets passed directly to D3D9, of which also hooks the window to handle a few things) and am currently investigating what may be causing it.

[GrayFace]

No, compatibility is off.
The problem with mouse look is that game window is at -32000x-32000 coordinates with 160x29 size: https://www.dropbox.com/s/uqvlf8790dif4 ... 0.png?dl=0
This must also be the reason why when you start the game mouse starts at top-left corner rather than center of the screen. With mouse look it also looks up and rotates, I suspect it rotates left.

[Emjayen]

0.0.0.3/Alpha (23-5-2017)
=========================
- Added some in-game performance counters. Use the F7 key to toggle on/off
- You can now cycle the texture filtering mode in-game using the F8 key
- Implemented emulation support for MM7/8's software 2D rendering (see: "Software2D" in mmcl.ini)
- Fixed issue where cinematics would not be rendered
- Fixed bug in cursor bitmap updating (e.g, during casting)
- Fixed video memory leak
- Fixed a few issues with windowed mode.
- Optimization that will slightly reduce level load-time

No, compatibility is off.
The problem with mouse look is that game window is at -32000x-32000 coordinates with 160x29 size: https://www.dropbox.com/s/uqvlf8790dif4 ... 0.png?dl=0
This must also be the reason why when you start the game mouse starts at top-left corner rather than center of the screen. With mouse look it also looks up and rotates, I suspect it rotates left.

I noticed that too, and although strange, they're the same metrics irrespective of MMCL being used -- actual tracing of MM7Patch's shows all calls to relevant functions (e.g, GetClientRect) return sane values (http://i.imgur.com/Vs4XMzw.png)

It appears what's actually causing it is the game clips the cursor (ClipCursor) to a 1x1 rect, essentially disabling the system cursor. However, removing clipping it reveals a new issue: it seems your mouse-look is implemented based upon the system cursor (using GetCursorPos and such), but the game's cursor position is based upon [axial-relative] data via DirectInput, thus the game's cursor and system cursor are not synchronized (atleast, that's my theory -- I'm not entirely sure on how you've implemented it as I'm not that familiar with pascal)

The root cause may be that the game appears to have two separate implementations for the cursor itself even; notice that with MMCL there's a seperate thread that's handling DirectInput/the cursor, yet without MMCL, this path is not used and is likely what you've designed MouseLook against. Similarly, with MMCL the game uses a different path for 2D rendering due to the different device caps.

I'll have to look into this some more.

EDIT: OK, the problem is that the game has two implementations for handling mouse-input (and keyboard, apparently) and MMCL is somehow causing it to use the path that uses DInput in a seperate thread (referred to as "asynchronous mouse" in the game binary). Interestingly, In software 3D the game never uses this method (even with MMCL), and mouse-look works fine.

[rnicknich]

Hey, created an account just to thank you for this amazing tool.

I noticed that mouse issue too, where it always goes to the top left corner of the screen. I hope there's a fix for that. But it's good enough to be able to play it on windowed mode already.

Thank you very much Emjayen. Also, a huge thanks to Grayface for the amazing patches. You guys are the best!

[Emjayen]

The mouse problem is a known issue and is the current priority to be fixed.

Glad to hear it's helped otherwise

[GrayFace]

Yes, I'm using GetCursorPos/SetCursorPos, I've no knowledge of DirectX. I can look into asyncronous mouse stuff.
[edit] So far I see that dword_DF1A74 is responsible for its activation, but I don't see what could set it to 1, I'll check in debugger.
[edit] It's "D3D Device" setting in the registry. If it's 1, async mouse is used. I'll fix it in my patch. I wonder what they did it for.
[edit] I removed checks for it: https://www.dropbox.com/s/y4oakom2hkttr ... 2.rar?dl=0
Now the cursor isn't drawn, but other problems (mouse look, crash with MMExtension) disappeared.

The old behavior with async mouse can be returned by adding this line to mm7.ini:
DisableAsyncMouse=0

[Emjayen]

Ah, nice find.

The reason it's crashing with greater resolutions is because the game is also being switched to software-2D mode with your fix, and support for greater resolutions requires the game to use its hardware-2D path.

While trying to fix this myself I managed to produce the exact same behaviour (software2D+system cursor) by exposing MMCL as the default device rather than a separate one -- it makes no sense, and I suspect it's a bug in the game since what controls the game using hardware-2D is the device capabilities reported by DDraw (which makes sense, the game uses hardware if possible, elsewise falls back to software) and I'm still reporting the same capabilities.

Unfortunately supporting software-2D with greater resolutions isn't really practical because it would mean reversing the game's entire 2D software path and patching it so for now I'm still continuing to look for a way to coerce the game into using hardware-2D, but with the system cursor (ie., not async mouse)

EDIT: Note that *2dacceloff*, although probably does refer to this feature, doesn't appear to have any effect whatsoever

EDIT2: You can switch to software-2D via MMCL's Software2D setting; this results in the game using software 2D with async. mouse, so presumably the inverse (hardware-2D, system mouse) is also possible.

Also here's a few relevant addresses (of your mm7.exe version):

0x0049E714 -- game calls IDirectDraw4::GetCaps. The game uses the returned caps to decide on which path to use (software or hardware -2D). I haven't checked which one it uses exactly, but I'm guessing it's hardware color-key support.

0x0043BBCF -- game calls IDirectInput::GetDeviceState. This is the async. mouse path.

Code: Select all

// seperate thread
for(;;)
{
      Sleep(18);
      EnterCriticalSection(..);
      IDirectInput::GetDeviceState(&rel_x, &rel_y); // for brevity; real structure is a bit more complicated
      
      // compute screen coordinates; DInput gives us relative mouse-movement data, not absolute. 
      this->cursor_x += rel_x; 
      this->cursor_y += rel_y;
      
      LeaveCriticalSection(..);
      
      DrawMouseCursorOnFrameBuffer(this->x, this->y);
      
      // I'm guessing the main game thread just looks at this->x/y for its purposes.
 }

[GrayFace]

You've probably responded to my previous version of the message. With my last version the game should act as always, just without the async mouse stuff.
Here are 2 instructions that you would need NOP'ed: 4A03F8, 4A09EB. They erase data returned by GetCaps if the async mouse switch is off. Then, I suspect you should be able to use native windowed mode of the game and set the tool as any device.

[waltc]

You've probably responded to my previous version of the message. With my last version the game should act as always, just without the async mouse stuff.
Here are 2 instructions that you would need NOP'ed: 4A03F8, 4A09EB. They erase data returned by GetCaps if the async mouse switch is off. Then, I suspect you should be able to use native windowed mode of the game and set the tool as any device.

I'm running WIn10x64, build 16226 (latest beta build), and I had been having a very rough time trying to get MM7/8 to open and run--previously, prior to the 10563 Creator's Update build of Win10 that Microsoft officially released a few weeks ago, I had no problem running either program with your 2.0 patches (or the earlier 1.6.x patches, either)--no need for compatibility modes and so on. But Microsoft has done something beginning with the official Creator's Update release of Win10 that has been causing some games that ran fine under previous builds not to run at all under the latest builds. They had been halted by "unable to open DX renderer" errors of one kind or another. It was very frustrating as I have a 2560x1440 monitor and did not want to have to drop down to 640x480, anyway.

Good News is... Grayface, your M&M7/8 modifications to Angeldeath's original scaling mods work like a charm (AD's original mods never worked for me) even in the present Insider's build of 16226! I've got both MM7&8 scaled to run @ 2560x1440 in a window--which is what I've wanted for several weeks now! Works splendidly! Thank you thank you thank you! Just want you to know how much I appreciate your work on these original masterpieces that after decades I still fire up and play every now and then!

Using mmcl .03 alpha...could not get it to run at all in M&M6; but seemed to at least allow me to run M&M7 @ 640x480 full screen, but Mouselook caused the direction to spin like a mad top every time I turned it on... Bottom line is that with the scaling modifications you made for MM7/8 from Angeldeath's earlier work I simply don't need to use mmcl any longer to get the game to run properly under these advanced Win10 beta builds--bodes well for the future! M&M6 is still a problem for me--right now I can only run it @ 640x480 in a Window, which is OK, just not where I want to be--maybe at some point when you have some time you could patch up something for M&M6 as you did for the M&M7/8 angeldeath mods...?

Thanks again for a very pleasant surprise! I also want to thank Emjayen for mmcl...because if I hadn't been able to get M&M 7 to run with mmcl I'd probably have just given up on them for a long while...! MMCL kept me interested enough to keep on looking! Thanks again!

Wanted to add one more thing, Emjayen. The very first time I ran M&M with the GF 2.0 patch and mmcl .03a, mouselook worked perfectly! I must've run through some things in the game for 30 minutes or so and mouselook was functioning fine--I remember because I had read your note about it breaking GF's mouselook and thought--"How nice, it's not broken after all!" OK, that said, the very next time I fired up M&M7 through mmcl, Mouselook was indeed broken and the viewport spun in rapid 360-degree horizontal revolutions like a mad monk's head... In every subsequent play Mouselook was indeed broken. But that first experience I had in which ML was working with mmcl .03a makes me think that a solution can't be far away!

[Emjayen]

Wanted to add one more thing, Emjayen. The very first time I ran M&M with the GF 2.0 patch and mmcl .03a, mouselook worked perfectly! I must've run through some things in the game for 30 minutes or so and mouselook was functioning fine--I remember because I had read your note about it breaking GF's mouselook and thought--"How nice, it's not broken after all!" OK, that said, the very next time I fired up M&M7 through mmcl, Mouselook was indeed broken and the viewport spun in rapid 360-degree horizontal revolutions like a mad monk's head... In every subsequent play Mouselook was indeed broken. But that first experience I had in which ML was working with mmcl .03a makes me think that a solution can't be far away!

I suspect what's occured is that the game has used it's normal mouse-input handling implementation on your first run -- this is what GrayFace has built his patch against and thus, why mouse-look functioned as expected. Usually with MMCL however, the game uses it's "hardware-accelerated" path which is what's responsible for all of the cursor/mouse related problems and is what's currently holding up 0.4

[waltc]

Wanted to add one more thing, Emjayen. The very first time I ran M&M with the GF 2.0 patch and mmcl .03a, mouselook worked perfectly! I must've run through some things in the game for 30 minutes or so and mouselook was functioning fine--I remember because I had read your note about it breaking GF's mouselook and thought--"How nice, it's not broken after all!" OK, that said, the very next time I fired up M&M7 through mmcl, Mouselook was indeed broken and the viewport spun in rapid 360-degree horizontal revolutions like a mad monk's head...;) In every subsequent play Mouselook was indeed broken. But that first experience I had in which ML was working with mmcl .03a makes me think that a solution can't be far away!

I suspect what's occured is that the game has used it's normal mouse-input handling implementation on your first run -- this is what GrayFace has built his patch against and thus, why mouse-look functioned as expected. Usually with MMCL however, the game uses it's "hardware-accelerated" path which is what's responsible for all of the cursor/mouse related problems and is what's currently holding up 0.4

Definitely makes sense...I seem to recall one of the registry controls turning async mouse on/off, is that what you mean? I think you are off to a great start, and with you and GF working together I feel that bodes well for us all! So good luck--if you ever need some testing, guys, let me know! (And I mean I *test*...something I've enjoyed for many years--who but a madman would be testing the Win10x64 *betas*!? But I do enjoy solving problems almost as much as I enjoy playing the games.)

As an aside, do you know what it is exactly that Microsoft is now messing with in DX/D3d backwards compatibility that has been causing the problems of late, since before the CU build of 10563?--I'm no expert, of course, but it sure looks related to changes being made to accommodate UWP--changes to Win32 compatibility to short-cut some things so as to enhance cell-phone, tablet, xBox & PC (I am strictly PC, of course, for obvious reasons!) simultaneous development cycles? I personally don't like the idea at all--and feel that something is going to suffer and right now it's the PC environment that seems to be drawing the small end of the stick!...;) Don't know if you are interested in this sort of thing--thanks again for working on these classics with GF--I think these games are worth saving, preserving, and enhancing--there's just something about them! Just want to let you know that some people like me and others I'm sure appreciate your efforts!

I'd love to help--if you need me--anonymously and discretely, of course (you'll know who I am but I don't advertise it and I don't speak out of school, etc.)--OK, didn't mean to make this sound like a spy drama...:D Thanks for the reply, and when it's convenient for you when you have a few extra moments and if you are inclined you may pm me here and we can chat! If not, no problemo...;) I completely understand.

Anyway, thanks again for your efforts--OK, I've shut down the flowery speech, I promise! You guys take care and I'll be following with interest!

[GrayFace]

Emjayen, I tried to write a PM to you, but the forum is buggy. Send me an email to sergroj at mail ru. I think we could work together on this.

[waltc]

Thought I'd check back and let you guys know that as of Win10x64 build 16232...released yesterday...the D3d problems relative to backwards compatibility with older games like M&M6-9 seem *fixed* finally--I can run all of them full screen now--the standard F4 controls are working again. Still need to run scaling mods to open MM7/8 in a higher-res Windows, but still scaled. Note that I am using the GOG versions these days ("dogs" apparently ate all of my original CDs long ago--really, I hate it when I can't remember what happened to my original copies of decades gone.) Just as well, though as the GOG versions were also problematic with the newer Win10x64 builds.

FYI, what Microsoft was trying to shoehorn into Windows (again) was something called "Game Mode"--which, after some testing and correspondence with them, turns out consisted of some crummy .dlls relating to *Xbox* compatibility in Windows10 which Microsoft was thinking of grafting into Windows 10...! Bad idea--these .dlls were attaching themselves to various game executables and creating horrific compatibility problems, as you might well imagine. The short of it is that after many suggestions from lots of people aside from myself Microsoft has turned off "game mode" by default--now--as it was enabled by default earlier and could not be turned off by the user. It's now entirely optional as it should be. Everything relating to "game mode" is now optional. Thought you might like to know that that much of it, anyway, has been resolved and backwards compatibility has been preserved.

[GrayFace]

MS stays true to themselves Reminds me of how they've added compatibility rules for all sorts of old games just to make them show up in Game Center (or something like that). The rules work like this: if exe is MM6.exe, gameux.dll is launched, it tries to connect to something, wastes a few seconds, then exits and the game proceeds to launch. So, renaming mm6.exe to anything else would greatly speed up its loading.

[GrayFace]

Incorporating Angel's resolution mods into my patches and solving resulting movie display issues ultimately led me to discover a way to add 32 bits color support to my patches and potential hi-res support.
The software 2D path does all its work copying the drawn interface to back buffer in the function 4A590D.
[edit] The thing I don't know how to solve with hi-res yet is how to change 3D view middle point and boundaries without effecting UI.