Dehacked Port Compatability

[Russell_P]

Do most/all current ports recognise the DEHACKED lump, or is that a Zdoom specific lump?

[myk]

Heh, that's an MBF feature/invention. You can imagine PrBoom and Eternity have it, and so does Legacy, and most likely Risen3D (haven't checked.) Not entirely sure about EDGE, or JDoom, at this point.

So, yeah, many do support it.

[Russell_P]

Thanks. My knowledge of port history is almost non-existant so you'll have to forgive me if it was a stupid question ;)

[wildweasel]

EDGE supports DeHackEd. Whenever it detects such a lump within the wad file, it converts all the DEH information into equivalent DDF. As far as I can tell, this works well enough with most vanilla or Boom-compatible DEH files.

[DaniJ]

Do most/all current ports recognise the DEHACKED lump, or is that a Zdoom specific lump?

Not entirely sure about EDGE, or JDoom, at this point.

jDoom does indeed support deh patches in DEHACKED lump form. However the "advanced" BEX [CODEPTR] stuff is not currently supported.

I'm pretty sure that practically ALL the current ports support DEHACKED. At least to a certain degree.

[EarthQuake]

DaniJ said:

However the "advanced" BEX [CODEPTR] stuff is not currently supported.

Are you saying that only the boom codepointers are not supported, or the entire format?

[DaniJ]

Are you saying that only the boom codepointers are not supported, or the entire format?

Doomsday - dpDehRead.dll:
Standard deh "Pointer" patches ARE supported.
The bex "[CODEPTR]" patches ARE NOT supported.

[myk]

EarthQuake said:
Are you saying that only the boom codepointers are not supported, or the entire format?

The BEX format. As far as I know, Boom uses the same code pointers as Doom (the "things" are the same), except you can place them anywhere, or you can nullify a pointer on a frame. BEX changes some of the format, also adding a bit of stuff (such as par time modification) and allows greater freedom (to reference a second patch, longer strings, etc.)

MBF may have added some pointers (bouncing things, dogs, etc.), and ZDoom added some stuff. You might be thinking about either.

This has nothing to do with the DEHACKED lump, but the engine that has the most accurate DeHackEd support is Chocolate Doom, since Boom and other engines are unable to modify certain text strings, some of which can alter the behavior or the appearance of the game. In some engines this lack can be offset somewhat by some enhanced features (MAPINFO, etc.)

[EarthQuake]

myk said:

The BEX format. As far as I know, Boom uses the same code pointers as Doom (the "things" are the same), except you can place them anywhere, or you can nullify a pointer on a frame. BEX changes some of the format, also adding a bit of stuff (such as par time modification) and allows greater freedom (to reference a second patch, longer strings, etc.)

So none of the boom specific stuff that you mentioned will work. Just trying to get some clarification. Initially I thought it had partial support. Looking back, some of the things people said make sense now. Sorry, shoulda been thinking.

[DooMAD]

DaniJ said:

jDoom does indeed support deh patches in DEHACKED lump form. However the "advanced" BEX [CODEPTR] stuff is not currently supported.

The same applies for Legacy, although full BEX support is planned for the upcoming 2.0 version.

[DaniJ]

I'll probably implement full BEX support in Doomsday's dpDehRead.dll at some point in the 1.9.x series.

Currently the dpDehRead plugin accesses shared, public data structs in Doomsday which defies the concept of a plugin system and the data ownership model. Basically this means we need to implement a proper API to the engine internal databases.

The Doomsday public API/ABI are currently being redesigned for 1.9.0 so once that work is complete I can then look at BEX support.

[Grazza]

myk said:

This has nothing to do with the DEHACKED lump, but the engine that has the most accurate DeHackEd support is Chocolate Doom, since Boom and other engines are unable to modify certain text strings, some of which can alter the behavior or the appearance of the game.

Though it should be mentioned that, apart from the test deh that I created specifically for the purpose (link), hardly any wads use the highly obscure parts of dehacked's Text section that only Chocolate supports at present (e.g. stats screen, status bar, iwad names).

The most annoying this about Boom's support in these areas (i.e. the ones that it does support, such as sprites, musics and sounds) is the error in the logic where there are cyclic changes. But again, these are quite rarely-used features.