Handle DMX midi issue? about chocolate-doom

[andrikpowell]

Just some thoughts...

1. Over the years, how many wads out there were created like this and will now trigger annoying errors? Is it too late to do something like this?

I'll admit it's a bit late to implement this, but as a mapper I use Chocolate Doom to check if a map/wad is Vanilla compatible. With how midi is treated at the moment, Chocolate Doom isn't exactly representative of how Vanilla Doom works.

This could result in future wads crashing in Vanilla Doom, as midis are constantly being made (or even older midis which I've had the format 0 issue more common) and if they are made incorrectly, the only way for a mapper to know if it works right is if they test it in Vanilla Doom via DOS.

I do think it'd be very useful to have this feature added to more modern testing ports like CRL.

2. In the link above there is a hack/workaround mentioned where adding at least 3 dummy bytes avoids heap corruption and then the format 0 midi plays okay in vanilla Doom. How many authors used this hack? Should we detect this and allow these hacked midis to play?

I'll just mention that the way I fixed the midi was opening the format 0 midi in Sekaiju, where it would throw a "midi is format 0, would you like to convert to format 1?" message. I don't really know anything about any dummy bytes, and the only reason I was able to fix the midi for myself was because I work with and am used to writing midis.

3. Should the format 0 midi detection be configurable?

No comment. I use Chocolate Doom as a testing tool more than actual playing.

[ceski-1]

I'll make a PR later. Some additional notes:

Only MUS supported (MIDI is silent):

• Doom 1.1, 1.2

Type 0 MIDI crashes game unless padded with 3 or more bytes:

• Doom 1.666, 1.8, 1.9
• Ultimate Doom 1.9
• Doom 2 1.666, 1.7, 1.7a, 1.8, 1.9
• Final Doom 1.9, 1.9 Anthology
• Heretic 1.0, 1.2, 1.3
• Hexen 1.0r1, 1.0r2, 1.1r1, 1.1r2
• Strife 1.0/1.1, 1.2, 1.3, 1.31
• Chex Quest

Error messages:

Z_CheckHeap: block size does not touch the next block

or

Z_CT at w.wad.c:510

[rfomin]

So, should Chocolate Doom exit or print a warning when a format 0 midi is detected?

Printing a warning is not enough, we don't even enable console output on Windows. I think we should use I_Error().

[ceski-1]

Yeah, maybe I_Error() is more appropriate.

Now, some other considerations:

1. Over the years, how many wads out there were created like this and will now trigger annoying errors? Is it too late to do something like this?
2. In the link above there is a hack/workaround mentioned where adding at least 3 dummy bytes avoids heap corruption and then the format 0 midi plays okay in vanilla Doom. How many authors used this hack? Should we detect this and allow these hacked midis to play?
3. Should the format 0 midi detection be configurable?

This is why I didn't create a PR yet.

[rfomin]

Over the years, how many wads out there were created like this and will now trigger annoying errors? Is it too late to do something like this?

A quick search in my collection shows that MIDI type 0 is only present in limit-removing or higher PWADs.