General Questions on DeHackEd

[Ed the Bat]

A little while back, Freedoom made itself a DeHackEd patch in order to give itself custom strings. This, however, lost it some compatibility with PWADs that, themselves, use DeHackEd. Since their original mission included PWAD compatibility, this struck me as unusual. Skimming their forums, what I picked up essentially said that this is due to shortcomings in how the majority of modern source ports parse DeHackEd lumps. I've seen this in ZDoom, where as far as I can tell, only one DeHackEd lump or .deh file can be loaded at one time.

Basically, I'd like to know a little bit of background on the circumstances that led to limitations such as this in ZDoom, and to a lesser extent, other ports (I'm less concerned with others, but if it's relevant, I won't mind learning it). Going by posts in these threads from Doomworld...
http://www.doomworld.com/vb/freedoom/59360-dehacked-problems/
http://www.doomworld.com/vb/freedoom/54906-dehacked/
...I get the impression that Fraggle feels this is an issue that deserves to be addressed in affected ports, and would also be a relatively simple issue to tackle. Does anyone happen to have any insights on if this is accurate (assuming I interpreted everything correctly), reasons why it should/shouldn't/can't be done, or any other relevant information? I understand it's a fairly minor issue, but curiosity has the better of me, so I thought I'd pose these questions to people who know the technical aspects better than I do.

[Galaxy_Stranger]

I can't imagine needing Dehacked for anything these days. Between ACS scripting and Decorate, you can do nearly anything you can dream up.

I always understood Dehacked support to really be for keeping things compatible with mods that used it, not for new mod development.

[Ed the Bat]

That's another reason I felt it unusual for them to use it. However, since they want compatibility with multiple source ports (essentially anything descended from Boom), they need a relatively universally-usable method.

[Syfo-Dyas]

Hence the reason I still use it. I'd personally hate to see my work (for better or worse) confined to DOOM engines that can only run on main stream OS'. So for that reason I am developing for Odamex (ZDOOM 1.2x), and can easily modify and alter my maps a bit to also work on PrBOOM. I'd love to take advantage of ACS more, and certainly would love to dive into Decorate, but until they become features in some of the more OS portable variants of the DOOM engine, I am confined to DeH and Bex myself.

[Ed the Bat]

Also, if I'm not mistaken, Chocolate and Vanilla Doom are essentially limited to DeHackEd for any kind of gameplay changes. Considering all of this, one could safely say that DeHackEd still has a place in this world, as things stand now. And knowing that, I feel it's worth my time to look into whatever limitations ZDoom has in that regard, and what might be done about them, if anything.

[Syfo-Dyas]

I'm all for it, I think the more compatible engines are with one another, the better in the long wrong. For instance it still kills me to see so many ports shrugging off some of the old MBF features simply because they have developed a new method to do the same thing, I.E. creating a Dog that helps the player fight enemies.

On that note, I have a feeling you and I are probably alone on this issue.

[Ed the Bat]

I am a huge proponent of compatibility. I go to (admittedly) stupid lengths to keep my project as compatible as possible with as many other projects as I'm able. So, if I see some kind of compatibility issue, even in things I'm not involved with, I grow curious about possible solutions. Sure, there isn't always a good solution, but it can't hurt to ponder, right? And if what Fraggle says is true, and this DeHackEd issue is indeed treatable, I would consider that a victory for compatibility. I'm personally not a fan of DeHackEd since I work exclusively in ZDoom and I can do more of what I need via DECORATE and ACS, but I know DeHackEd is useful for a lot of things, and fixing anything that may be going wrong with it would always be a good move, assuming it's feasible to do so.

[Enjay]

I find that users have quite a bit of inbuilt compatibility. If there is a mod they want to play enough, and it requires a specific port, they will use the port required. I know that I do that.

Personally, I'd rather not limit what I want to achieve in my projects to gain high levels of cross port compatibility. In fact, the kind of cross port compatibility that is being talked about here would mean sacrificing almost every feature that is important to me in ZDoom.

[Syfo-Dyas]

See, now if I'd never used an Amiga I'd be alright, I'd happily be using GzDOOM with all it's features and this and that, but nooooo...

....I gotta be difficult and have to be dead set on creating something that will run on modern Amiga OS'.

Who knows, maybe some day a nice Open Source Audio Library will come along for ZDOOM to switch to. That's all that keeps it from being very portable right?

[Enjay]

Funny thing, only yesterday I was thinking that I'd like to see an Amiga OS running on decent modern hardware.

Out of interest, are there many people who run Amiga OS and nothing else (ie they don't also have a Win/whatever setup)?

[Syfo-Dyas]

There are a few die hards out there like that. In fact I know a couple who strictly use only classic Amigas, but most of us have another machine near by, be it for Linux, OS X, or Windows.

Funny you should bring that up, an interview with one of the developers of the MorphOS (a modern PPC Amiga clone) was recently put up and in that they ask him if he sees MorphOS ever rising up to the position of being able to compete with Apple, Microsoft and the like, and he said never, it is a niche OS for hobbyists only, there will always be a need for a computer with a main stream OS near by as there are just too many drivers and apps readily available for them.

Hence the reason I run Windows, so that I have access to those specialty apps that Amiga OS variants do not have.

Anyhow, as far as Amiga on modern hardware, oh yes, there is a lot of that going on. Sometimes pricey, sometimes not so much so, depends upon your flavor and needs.

We got AROS, Amiga OS 4.x, and of course MorphOS, all of which are constantly being developed. Some are pricey, some are free, but if you are an ex Amiga user, I'm sure you might find at least one of them of interest. Heck we just recently acquired the ability to use a ATI Radeon 9200 on an old Amiga 4000. And I think they now have a work around for that in relation to the Atari Falcon too, how cool is that?!

[Galaxy_Stranger]

That is fascinating information about Amiga. Go to Retro Gaming Roundup and Retro Gaming Radio and tell them about this. I'm sure they'd love to hear about it. I always love it when I hear when someone's running a web server on a Commodore or whatever.

until they become features in some of the more OS portable variants of the DOOM engine, I am confined to DeH and Bex myself.

Now, this is an interesting point. Generally, Windows, Linux and MAC are taken care of. Since the source for many of these ports have been released, I wonder how much work it would take to port ZDoom and Zandronum to Amiga?

[Ed the Bat]

This has been a fine discussion. However, if I could please have my topic back for a moment...?

What it really boils down to is this: Can ZDoom's DeHackEd support be fixed as easily as Fraggle seems to think? If so, why hasn't it yet? What would it require?

[Syfo-Dyas]

My apologies.

[Gez]

What it really boils down to is this: Can ZDoom's DeHackEd support be fixed as easily as Fraggle seems to think? If so, why hasn't it yet? What would it require?

Well, first it'd require to know what is the problem exactly?

Just to be sure, I tested various sourceports:

chocolate-doom 1.6.0: no support for wad embedded DEHACKED lumps
boom 2.02 : no support for wad embedded DEHACKED lumps.
prboom-plus 2.5.1.0 : only last loaded DEHACKED lump is parsed. *
edge 1.35 : only last loaded DEHACKED lump is parsed. *
zdaemon 1.08.08b : only last loaded DEHACKED lump is parsed. *
Doomsday 1.8.6: only last loaded DEHACKED lump is parsed. *
mbf 12/22/1998 : loads both DEHACKED lumps, string replacement has the issue quasar described.
Doom Legacy 1.44.0 alpha2: loads both DEHACKED lumps, string replacement has the issue quasar described.
eternity 3.40.11 : loads both DEHACKED lumps, but string replacement works anyways.
zdoom 2.5.0 (r3218): loads both DEHACKED lumps, string replacement works.

Am I missing something here? It seems ZDoom (along with Eternity) is already behaving in the correct way; whereas other ports have a variety of issues.

Now, this is an interesting point. Generally, Windows, Linux and MAC are taken care of. Since the source for many of these ports have been released, I wonder how much work it would take to port ZDoom and Zandronum to Amiga?

The hard part is changing the sound code from [wiki]FMOD Ex[/wiki] to something else that also exists on the target platform. This may require dropping features from ZDoom, such as support for a ton of formats that are supported natively by FMOD Ex, and perhaps more importantly the reverbs. But anyway, once you've done that, porting shouldn't be too hard. The code is already friendly to non-Intel processors (endianness checks, plain C/C++ alternatives to ASM code).