fabian

Guys, the Crispy release binaries get compiled on @fraggle's auto-builder for Chocolate Doom. As far as I know, they are cross-compiled on an non-Windows system using MinGW, so the chance that they have been infected by an actual Windows virus are marginally low. Also, this setup hasn't really changed since at least the Chocolate Doom 3.0 release.

These seem to be nothing more than a bunch of default settings: https://github.com/Sakitoshi/mbf_sigil/blob/67faf637cfdc812eb8fa7fc218a2a34f60aa851b/m_misc.c#L1962 However, benchmark results achieved with these settings are not comparable to a SDL-based port anyway, thinking of how differently rendering features like e.g. vsync are implemented.

Nope, sorry, this is not on the agenda - ar least not currently. AlexMax already offered to add an implementation but I declined. Frame interpolation means too many code changes in too many places all over the code - that's also the main reason against the WiggleFix. Also, there is no canonical reference implementation - what looks good in Crispy might yield unusable results with a different code base. It's just too much hackery. While this is okay for Crispy - which I consider my own code - I am a lot more reluctant in this project because I still consider this as Lee's code. And changes like these are just too "un-MBF". This is a bit more probable, I'll look into it.

You could bring these issues back to attention by quoting them in the Choco thread and posting something like "Hello?" or "ping". Or you file them as bugs on the issue tracker at Github. But I am not going to dig through these threads myself, sorry.

Nope, never cared. Are there any specific features that you'd like to see in Woof?

Sounds like a good idea, done that. Where did you have this reported before? The fix seems alright, Doom already has a similar condition there. Well, it won't help to throw everything at my feet in this thread. Everything sync-related (that doesn't involve raising limits) is relevant for the Chocolate project. Development takes place at Github, so it would be most appreciated if you could take the issues there. Alternatively, please post your concerns into the Choco thread in the Source Ports forum. We are definitely interested in improving demo compatibility and any help will be appreciated (especially for Heretic, which hasn't seen much love since it was added to the code base).

The port doesn't crash anymore even if the limit is vastly exceeded. For smaller amounts of limit exceeding the overflow is still properly emulated.

Not at all. The overflow emulation is still there, but the array now resizes dynamically.

You guys might be interested in this: https://github.com/fabiangreffrath/crispy-doom/commit/62949d06e4e2fffec10f9e2c33745e402b1a13da This is the corresponding EXE: crispy-heretic_5.7.2+git5a6726c4.zip

Ad 1) AFAIK it is only possible to bind max. 5 buttons with SDL. Ad 2) For the reason pointed out above, it won't make sense to add a separate key binding for each weapon. But if you want something like a button for "favorite weapon" and a way to define this in the config file, that's something we could agree upon. Thanks for the feedback! While I generally prefer requests or bug reports to be filed at the Github tracker, this here is a perfectly appropriate place as well.

There was some desync in Russian Heretic, but it was fixed some time ago: https://github.com/JNechaevsky/russian-doom/commit/dc0a9a95fca6c7668833d91816a6627822703b87

Either this has never been brought to my attention or I am simply too much occupied with other stuff...

I have just released Woof! 1.1.0: The port is now more forgiving when a flat lump cannot be found and renders the sky texture instead. Mouse acceleration has been entirely disabled. The rendering of flats has been improved (visplanes with the same flats now match up far better than before and the distortion of flats towards the right of the screen has been fixed). Some nasty rendering and automap glitches have been fixed which became apparent especially in extremely huge levels (including the "long wall wobble"). Demo compatiblity with Boom 2.02 has been improved (including the 3-key door bug fix). Maps without level name graphics do not crash during the intermission screen anymore. Vast overhaul of the CMake build system (@AlexMax). Screenshots are now saved in PNG format using the SDL2_Image library. https://github.com/fabiangreffrath/woof/releases/download/woof_1.1.0/Woof-1.1.0-win32.zip

Update Mar 13, 2020: Crispy Doom 5.7.2 is released! Crispy Doom is a friendly fork of Chocolate Doom that provides a higher display resolution, removes the static limits of the Doom engine and offers further optional visual, tactical and physical enhancements while remaining entirely config file, savegame, netplay and demo compatible with the original. Crispy Doom 5.7.2 has been released on March 13, 2020 to introduce the Compact HUD for widescreen rendering mode and bring some general improvements and fixes. Please visit the Crispy Doom homepage for more information: https://github.com/fabiangreffrath/crispy-doom/releases Binaries for Windows (x86) are available here: https://github.com/fabiangreffrath/crispy-doom/releases/download/crispy-doom-5.7.2/crispy-doom-5.7.2-win32.zip Have a lot of fun! - Fabian

Why only "mostly"?

This. And virus scanners regularly identify it as malware. Yay, Windows!

Since you didn't post the error that you encountered, it is hard to tell what went wrong. Generally, I would try to do what the ./travis,sh script does: mkdir build && cd build cmake -G "Unix Makefiles" .. make Thank you! This is a well known bug, especially with SDL-based games. For whatever reason, Windows doesn't allow a single process to change its music and sound effects volume separately anymore. Some source ports help themselves by introducing another process (midiproc) which takes the part of MIDI playback, but I am currently not working on that.

Possible sure, but I won't work on this.

Yes, of course, else regular MBF demo would desync!

These demos do not desync anymore, and they do not crash in the intermission screen anymore with the newest state in GIT. Unfortunately, this WAD doesn't load in WinMBF ("R_GenerateLookup: Column without a patch in texture ..." for 123 textures), so it's impossible to know if the desync occurs there already (which I believe).

I have added support for drag-and-drop to Choco some time ago, so the next release will have it and Crispy already has it for some releases. The same implementation is now used in Woof!: https://github.com/chocolate-doom/chocolate-doom/commit/0abcb12fbbf199fa561da03794326e242b94018d Well, this is MBF. So, if PrBoom+ created an MBF demo and it desyncs this could just as well be a bug in PrBoom+ o_O. Anyway, would you please tell me which WAD and demo that is?

What does this mean, could you please be a bit more specific?

Oh, indeed, I need to enable the fix for Boom but keep it disabled for MBF demos. Thanks for the reports, people, this is really helpful!

Nope, no new features are planned. This will stay MBF.

It's a Boom 2.02 demo, so it should be supported. Sync is fixed in GIT, thanks for noticing! Edit: BTW, this is already desyncing in WinMBF.