Potential Further Resources

[Chromatophore]

Hi,

Really sorry, I don't know how to reach you other than this - I am Mastigophoran and only just became aware of your project here. If helpful, you can contact me via that name @ gmail.com - Evidently, I'm Chromatophore here on github.

All the way back from when I was trying to find some options to play the game again, I generated a folder containing a large number of binary files which I created with MMF with the different graphical modes selected. This is how I originally figured out getting the game to run in this windowed mode. I'm not sure if you're familiar with the menu page I'm referring to, but in my mind the real 'goal' option would be the option to support graphics scaling, which was a feature the MMF graphics engine did support. But, I never managed to persuade the ED binary to do it.

I've since lost the copy of MMF I was using but I do still have a folder of slightly poorly named binaries. If you are interested in pursuing this project further, I can supply either the binaries or at the very least I would suggest trying to get a copy of MMF 1 to investigate further.

Thank you for the work and effort you've put into this project.

[Chromatophore]

A short distance after PAME, please try setting byte 0x79C74, regular value DD to 2D.

This is apparently all that was needed to enable the stretching to fit the Window space graphics mode.

This has a large number of interesting interactions with your new drawing mode options. Any time you draw black space that doesn't get rendered into, the display will (unevenly) stretch to fit that area. Combining this with -u is often bizarre.

However, I'm sure you can see the implication of what this allows us to do: with the original -nof mode, a whole black screen that fills your display's native resolution with a tiny game window in the middle - this value change should allow us to once again run the game in an effective full screen display.

I would like to figure out though if it is possible to support a larger default size window mode in order to try and preserve aspect ratio. Presumably we can convince the game to somehow create a 640x480 window when in windowed mode, and then with this value active, have the game contents stretch to fit.

• nb 0x6D also works in this location - again these are values pulled from binaries.

[mmiszczyk]

Hello @Chromatophore . Sorry for late reply, I didn't notice that the issue was created (Github doesn't send e-mails unless I subscribe/comment/assign myself/etc.). This is indeed very interesting, and makes me want to try combining this with the pseudo full-screen mode. Unfortunately, making any changes to the project would require some rewriting because the Hy language made some breaking changes between versions and this just won't compile under the current ones. This wouldn't be a big loss because the code was pretty bad, but I'm a bit busy now so I'm not sure when I will have time to do it. Hopefully I'll find some time in June/July.

[mmiszczyk]

A rewrite in general would be a good opportunity to fix some of the other issues with this project:

• making a graphical launcher with user-friendly way of picking settings
• making a graphical save editor
• creating a version that has no dependencies on either prebuilt binaries or a Python runtime
• compiling the bmploader with a non-ancient, still maintained toolchain

In general I'd probably move the whole thing from Python and Hy to a language that compiles to either native code or .NET. There's not that much code so it won't be that big of a time investment, but it'll need to wait a bit. Fortunately, we still have time until 20th anniversary :D

[Chromatophore]

Hello! It turns out that your project here has now helped tune me into x86 reverse engineering! So, thank you very much for that! I have also been very busy, but if at all possible I'm keen the see such a project succeed.

I think you have some good ideas. Honestly, I would like to suggest adding a specific goal for the project: track down the method by which ED plays midi files, and change it, so that it doesn't hang the dang game every single time. Important addresses I pulled from Ollydbg: ED->cnc.dll were I think based on sketchy several month old notes: 00041120F, and then specifically in the original packed mmf dll 1002B49E, and for the patched one 1002CB91 ish? My understanding is that it's using WinMM and mciSendCommand with commands like 804 (stop?), 803 (stop?), 806 (start) and 804 (?) - importantly, all the game's desires to start/stop music all hit this area of code. The process by which the game operates is to extract the midi to a temp folder and then provides the path to this part of the code - the hanging is so far as my understanding extends to, due to changes to WinMM.

My knowledge of how best to make use of the above info is... primitive at best, but, we should have a file path and a common area of code and knowledge of what the game wants to happen to the music.

I also tried using OmniMidi ( https://github.com/KeppySoftware/OmniMIDI ) to try and smooth over the issue. It didn't help with the hanging, but, it did help with soundfonts.

Anyway, I also missed your response message but I mean, I'm a real big fan of multi-year random message exchanges! One month between each message is a big upgrade.

[mmiszczyk]

So the updated cncs232.dll is not enough to fix the playback problems? That's disappointing.

As for the MCI commands, I did some digging and found that they're defined in mmsystem.h. 0x804 is MM_CLOSE, 0x803 is MM_OPEN, 0x806 is MM_PLAY. For the sake of completness, stopping is 0x808 and pausing is 0x809. You can find those commands in mingw sources https://sourceforge.net/p/mingw/mingw-org-wsl/ci/4.0.0/tree/include/mmsystem.h#l630

[Chromatophore]

Neat, I was hoping to find the actual numbers involved in the definitions on ms pages but never did.

Unfortunately the hanging seems to be a windows thing, and that has impacted many different people in a variety of ways. Interestingly, the updated cncs232.dll does fix most other problems and it does kinda improve midi playback in one specific way: It adds a very clumsy loop to the end of the midi. As a result, midis that repeat don't hang the game with the newer dll, where as with the older dll they do hang. If you add some break points to that area, you'll find that the older dll hits that area of code each music loop, but the newer one does not seem to.

[mmiszczyk]

If it's really a Windows thing then I don't see a good solution, other than replacing the entire MIDI solution with something non-native. Or, if we have time/patience/skills for that, drop the MIDI thing entirely, get real audio playback and patch in the 10th anniversary soundtrack