DeHacked for graphical correction without changing gameplay

[Ultraviolet]

I know it is not within the aim of this project to change the gameplay, only the graphical part of the "look and feel" of the game, but I noticed something playing the latest release today.

The BFG ball looks REALLY, REALLY NICE in ZDoomGL -- beautiful, fuzzy, nebulous. However, the effect was lost when it hit. That. Chunk. By. Chunk. Animation. Sucked. If it were sped up to use frame durations of 2, though -- yes, it would fade faster than the original, but that has no gameplay impact -- it would be very believable, and keep that nebulous fluidic feel.

The same should be done for a lot of sprite animations in Freedoom. The plasma spiral comes to mind. Spinning fast and exploding fast it would look quite convincing.

The animations in the original were geared toward slow frame rate, so it worked. Freedoom's sprites don't seem to be made with that in mind. Perhaps there should be an optional component, a separate download, optional but suggested, a dehacked patch to change the speed of some of the animations only.

Just a suggestion.

[wildweasel]

This would be most welcome. The teleport/respawn flashes are excellent with shorter frame delates, and the Chaingun just feels better if it's sped up without incresing the firing speed.

[Jon]

Some ports support an embedded DEHACKED lump in WADs. How does thie effect wads that don't support it? Are there any compatibility options between ports that do? I.e. what would be the ramifications of including such a lump in the FD wads?

[Ultraviolet]

WildWeasel said:

teleport/respawn flashes

Another good example I forgot!

Jon said:

Some ports support an embedded DEHACKED lump in WADs. How does thie effect wads that don't support it? Are there any compatibility options between ports that do? I.e. what would be the ramifications of including such a lump in the FD wads?

I'd assume vanilla would just ignore the DEHACKED lump. BOOM-supporting ports, which most are now, support DEHACKED lumps, don't they? If both of these are the case, then I can't see any problems.

[Quasar]

There's a chance such a modification could cause demos to desync. Also, it further limits compatibility, and some ports (I will not name names) have rather unstable DeHackEd support.

[Ultraviolet]

Quasar said:

There's a chance such a modification could cause demos to desync.

Why on the purely cosmetic ones? I could understand if we did it to something that has a bunch of codepointers thrown into the animation sequence, but the rate at which, say, the plasma ball animates doesn't affect whether it exists in the game or how fast it is travelling. I think there are a lot of sequences we could speed up with no ill effects.

Besides, demos sux lolol.

Also, it further limits compatibility, and some ports (I will not name names) have rather unstable DeHackEd support.

Legacy? JDoom?

[myk]

Ultraviolet said:
Why on the purely cosmetic ones? I could understand if we did it to something that has a bunch of codepointers thrown into the animation sequence, but the rate at which, say, the plasma ball animates doesn't affect whether it exists in the game or how fast it is travelling. I think there are a lot of sequences we could speed up with no ill effects.

But some do, apparently; I recall one that Grazza had recorded without a hack that went with the wad being played that did little more that turn the Hell Knights partly invisible, that would desynch with the hack.

Besides, demos sux lolol.

But the whole point in this project is cloning the main wads in order to play existing wads made for DOOM and DOOM II. Had it been made simply to provide a free IWAD usable with existing engines not requiring full compatibility with id's IWADs or their depending PWADs, it would have certainly entailed much more creative freedom and perhaps would have summoned more focus and skill into its production.

[Grazza]

myk said:

I recall one that Grazza had recorded without a hack that went with the wad being played that did little more that turn the Hell Knights partly invisible, that would desynch with the hack.

The issue there was that other monsters responded differently to partly invisible monsters than to fully visible ones. Actually, I had used the dehacked patch, but in a version of a port where it didn't work correctly.

One other point: if such a deh patch were embedded in the iwad, it would impact pwads that replace the relevant graphics. For that reason alone, it strikes me as a bad idea. After all, as myk says, one of the main ideas of Freedoom is that it should work with existing pwads.

[wildweasel]

I'm still all for a DEH patch, but my suggestion is that it be turned into a seperate download (and ZDoom/Eternity/Boom users can set it to autoload).

[myk]

Grazza said:
The issue there was that other monsters responded differently to partly invisible monsters than to fully visible ones.

But is that really due to a behavioral diference for, or in respect to, semi-invisible monsters or is it due to some kind of overall secondary effect of the change produced? I say this because it doesn't evidently seem like other monsters are affected by Spectres' partial invisibility. If the latter is the case, it shows that miscellaneous changes to things could have slight effects on gameplay.

[Grazza]

I recall that I tested that in a few ways. When the semi-invisible monsters don't interact with other monsters, everything stays in sync. Example demos: st31-039 (no desync even if the invisible holobots, which aren't activated, are visible), eob6-148 (OK whether the hell-knight, which I kill, is invisible or not).

Obviously, all you'd need is one counter-example to disprove that, but I haven't found one yet.

As for the spectre/demon, making the demon invisible or the spectre visible can certainly cause desyncs when these monsters interact with other ones (tested with 30nm2956 and Eternity - desyncs in map03 with spectres visible, and in map05 with demons invisible). That could either support or undermine your theory - watching with a walkcam might help clarify where things start to go awry. But the real answer's in the code, I suppose...

[Graf Zahl]

If you use the SHADOW flag (which differentiates the Demon from the Spectre) to create translucent objects it will definitely impact the game's behavior. Aside from creating the visual effect this flag also affects a monster's ability to see anything with that flag (like when a player picks up the invisibility powerup.) So desyncs are not surprising at all.

The relevant code sections are the following in A_FaceTarget:

    if (actor->target->flags & MF_SHADOW)
	actor->angle += (P_Random()-P_Random())<<21;

and this in P_SpawnMissile:

    if (dest->flags & MF_SHADOW)
	an += (P_Random()-P_Random())<<20;	

[Jon]

Well that sums it up then. A DEHACKED lump cannot be included in the official IWAD, both because of desyncs, but also (and I'm embarrassed to have missed this) because it will mess up the timings for PWADs that replace the relevant graphics.

However, I have no problem putting the .deh lump available for download, as long as it is bundled with a description of the consequences.

Edit: thanks to all involved in this discussion for pulling up examples, code segments, etc. It has been thoroughly interesting!