Dasperal

For GUS emulation, you can provide a path to the custom set of GUS patches via "-gus_patches <path>" command line parameter or "gus_patch_path" config variable. For MIDI, you can provide a path to the custom Timidity config file via "timidity_cfg_path" config variable. There are the only working options right now.

They are almost equal, with gcc being a bit more performant and msvc being a bit less performant. The release builds are using gcc. Other dev builds are byproducts of compilation testing with different compilers.

Yes, I plan to release those changes. But I am not interested in DOS, so I probably won't develop new features for the DOS version of Russian Doom.

I am not saying that International Doom was abandoned, I am saying that the original codebase was abandoned. In 7.0 release, International Doom was rewritten from scratch in a new repository - JNechaevsky/international-doom. I asked permission and got agreement, @Julia Nechaevskaya can confirm. I can also provide a screenshot of the conversation in Discord (it is in Russian): More over, it is not really a fork, it is the original JNechaevsky/russian-doom repository transferred to me by @Julia Nechaevskaya. I chose the name Russian Doom, because it is the original name of the project and because this project preserves translation to the Russian language, no longer present in the International Doom 7.0+. I have to check how to implement it in the software render. If I will be able to implement it, I will probably do it.

Russian Doom is a limit-removing source port of Doom, Heretic and Hexen. It has numerous vanilla bug fixes, enhanced 640x400 and 1280x800 rendering resolutions, improved game palettes and offers many optional aesthetic game enhancements along with the maximum possible translation to the Russian language. For more information, visit the Project's Wiki. This is a continuation of the original Russian/International Doom codebase, that was abandoned with the release of International Doom 7.0. This project is distributed with the @Julia Nechaevskaya permission. Download latest version Release on GitHub Antivirus FAQ Get on Linux Changelogs GitHub repository

@Graf Zahl Yes, I tried. The main problem with this approach is that it returns control to the parent terminal (cmd, PowerShell, etc.) immediately after the process is started. This creates a situation when two applications control one console window simultaneously. This also means that when the process exits, you won't see the expected line with the current directory path and cursor, as it was already printed long before. Things become match more broken if you use Far Manager: . @Quasar This has the same cons as described above, but also as it spawns an additional process, it will trigger a lot of antivirus false positives. For now, I decided to make .exe and .com link a DLL with the main code, this cleared almost all false positives, but I can't guarantee that they won't come up again. And it's a very annoying work to try to bypass the stupid heuristic AI of antivirus. I don't want to do it ever again. If your antivirus still detects viruses in Inter-Doom distributions, report it to your antivirus maintainers as false positive. In my opinion the best solution to CLI problem is the initial one: Make only .exe, make it SUBSYSTEM:CONSOLE, immediately close automatically created console window if not needed. The only con is blinking of the icon of console window in the task bar (and blinking of the console window itself) that @Julia Nechaevskaya doesn't like. If you think that the blinking is ok, you can attempt to convince @Julia Nechaevskaya.

It is false positive. It comes from "inter-doom.com" file. If you don't use CLI, you can delete it. Q: Why does "inter-doom.com" exists? A: Because of Windows's stupid application types. App can either be Console or GUI. Only Console app can properly attach to parent terminal (cmd, PowerShell, etc.), but always creates new console window if there is no parent one. The first approach was to make Inter Doom a console app and close the console window when it is not needed, but @Julia Nechaevskaya didn't like the blinking window, so we decided to go with the console wrapper. The ".com" extension have priority over the ".exe" if no extension specified in the command line, like "inter-doom --help". The code of this wrapper originates from the Woof! source port and it's distributions also have false positives. At the beginning it had only 3/72 false positives and I managed to fix them for x64 builds by removing some function calls that read input stream code page and console mode. Now then it is 32/64 false positives, I think that we need to come up with more sophisticated launcher on Windows.