Boom derivative ports prioritize BEX over DEH?

chungy said:

BEX will still be used. It provides a nice property in that no copyrighted/trademarked strings from Doom are necessary in order to make text replacements (and it's overall a nicer format). Even Chocolate Doom supports loading Freedoom's BEX patch :)

A while ago I decided to check if the HacX v1.0 registered PWAD could be run with the Phase 2 IWAD in MBF. While this generally worked (with some minor issues), I noticed that the game would use Freedoom message strings instead of HacX strings found in HACX.DEH. Gez explained to me that this happened because MBF apparently gives higher priority to BEX than DEH, regardless of the order in which these may be loaded.

I have just checked PrBoom and PrBoom+ under the same conditions, and they also use Freedoom strings over the HacX ones. The rest of the DEH file is used normally, of course.

Apparently this means that Boom-derivative ports will not display custom strings that may come with PWADs if they are stored in the DEHACKED format. For a test, I tried a PWAD that comes with altered level name strings (this one), and both PrBoom and PrBoom+ still use stock level names from freedoom2.wad.

It is probably also worth noting that when I tried running the Plutonia: Revisited Community Project, which is supposed to be used with Plutonia, rather than vanilla Doom II, PrBoom/+ a did not use the Freedoom BEX strings but the original Doom II strings (the first map was called Entryway on the map screen) straight from the port executables.

As for the use of a DEHACKED lump in the IWADs, I've always assumed that the original Doom strings are parts of the source code, and the source code license extends to them too? Or is the problem in that the license is different from that of Freedoom? Can't the message strings be treated the same way as the file/lump names within the IWAD if they're never displayed in the game?

MrFlibble said:

I've always assumed that the original Doom strings are parts of the source code, and the source code license extends to them too?

The strings are part of the source code as built in constants.

The license does not cover the names of the levels because they are essentially like numbers and basic words.

GhostlyDeath said:

The strings are part of the source code as built in constants.

The license does not cover the names of the levels because they are essentially like numbers and basic words.

So does that mean that there's no problem using a DEHACKED lump for Freedoom strings if BEX conflicts with custom strings in PWADs?

MrFlibble said:

So does that mean that there's no problem using a DEHACKED lump for Freedoom strings if BEX conflicts with custom strings in PWADs?

DeHackEd strings are limited to a certain amount of characters, the original strings (in most cases rounded up to 4). This is because DeHackEd replaces the data in the binary so it can only use what there is room for. BEX does not have this limitation and is used by most Boom ports to replace strings and such.

While the strings from Doom are part of the engine's source code, not only is it GPLv2+, so we can't very well derive from that and maintain Freedoom's claim of being BSD-licensed (see drama recently about desiring to include GPLv2 resources), but they also contain trademarks of id Software (now owned by ZeniMax Media). id had never done anything about the engine. Lack of foresight and inexperienced caused John Carmack to hard-code many things into the engine that should have more properly been part of the game data (he did this approach in Quake and all later games). fraggle had actually emailed John Carmack in the early days of Freedoom, and got a response back offering limited support for the project -- but we couldn't name anything identically to Doom.

This is much of the reason we use BEX. It's a nicer format, and it avoids including trademarked strings, even as a technicality. It kind of sucks that ports don't exactly handle mixing BEX and DEH sanely, but that can always be repaired port-side, and I highly recommend fixing it there. Also, while Phase 2 is reasonably treated as equivalent to Doom II by default for string replacements, it could also be fixed with a paramater to switch this; Chocolate Doom has the -pack {doom2,tnt,plutonia} parameter to switch these, and for consistency, I think this is the convention other ports should adopt.

MrFlibble said:

It is probably also worth noting that when I tried running the Plutonia: Revisited Community Project, which is supposed to be used with Plutonia, rather than vanilla Doom II, PrBoom/+ a did not use the Freedoom BEX strings but the original Doom II strings (the first map was called Entryway on the map screen) straight from the port executables.

There are a different set of level name strings for TNT Evilution and The Plutonia Experiment.

In BEX there is:
HUSTR_ prefix is used for Doom 1 and 2
THUSTR_ prefix for TNT (iirc)
PHUSTR_ prefix for Plutonia (iirc)

Freedoom does not set THUSTR and PHUSTR strings (and probably shouldn't ?)

That's correct. Freedoom: Phase 2 should be treated by source ports as equivalent to Doom II by default. Chocolate Doom has that workaround I mentioned for a user to force the game to use a different set of strings by default (which is good for loading DEH files).

chungy said:

fraggle had actually emailed John Carmack in the early days of Freedoom, and got a response back offering limited support for the project -- but we couldn't name anything identically to Doom.

This is much of the reason we use BEX. It's a nicer format, and it avoids including trademarked strings, even as a technicality.

Well, I suppose that if the DEHACKED lump limits each string's length proportionally to their respective original counterparts, there's no reason even considering using it.

It's a pity that there's this issue with Boom derivative ports, meaning that ports which are no longer updated will not get a fix for this.

I suppose that the other way to address this issue would be to use dedicated executables for Freedoom that already contain the necessary strings. Which, again, relies on a solution that is external to the IWADs.

The new update of MBF provided a fix for this issue (sort of) in the form of a command line parameter that disables the loading of embedded DEH/BEX lumps.