[Bug/Feature Request] Desynced Flat Animations from Vanilla / Unity Port

[andrikpowell]

Hey Eternity team,

There's a certain effect that I'd like do have working in all ports, but it seems that the Eternity Engine port is not consistent with FLAT animations like Vanilla/Unity Port.

I found that in Vanilla it was possible to get flats and textures to be synced depending on the lump order.

Let me start by how flat animations work in Doom from my rigorous testing.

• Flat animation timing is synced exactly every time you load up a map, regardless of map if you have a flat that changes from blue>red>yellow>green, when you load the map and it starts on blue once, it will always start on blue.
• The timing of the flat animation is based upon on the lump order of the WAD. This means you can change the timing / first frame of the flat animation in the game, by moving where the first flat lump of the animation is. For example: say a WAD begins with FF_START, F_SKY1, and then SLIME01 with the first slime animation frames SLIME02-04 after. now say when you load the map, the level starts with the flat as blue, everytime you reload the map, it'll always be blue at the start. Now say you move SLIME01-SLIME04 above F_SKY1. When you load the map now it the flat that starts on map load is now green. Everytime you reload the map or any map in the mapset, the flat will always start on green.
• The flat animation order is determined locally per wad archive. This means that the lump order nor flat animation doesn't change depending on if you load wads before or after the wad with the FLAT lumps.
• Textures work in a similar way however instead of lump order, it is based on the order of textures in the TEXTURE1 lump. however they seem to be synced correctly in all ports, unlike flats at the moment.

The megawad I recently released uses this effect (MAP25):
200 Line Massacre
^ The flat and textures currently sync up with Vanilla / Unity Port.

I suggest this fix:
jeffdoggett/Doom@e2e0e69

Both Doom Retro and Woof have implemented this fix.
DSDA Doom has the fix currently underway (kraflab/dsda-doom#138).
It basically forces animations to start from the first frame (similar to how ZDoom ports deal with animated textures and flats).

In the 200 Line Massacre release video, it features the effect in action:
https://youtu.be/8wMEsuEDAxo?t=46

[sink666]

This is not actually an issue with EE persay, it's an issue with 200 Lines' EDF. It uses the Hexen format EDF animation to define its flats, which fires in a different function, always after P_UpdateSpecials. If you change it to a Doom format animation it will be synced. Below is the code of the fix that I sent to one of the authors. This was such a nightmare to hunt down.

animation
{
  flat SLIME01
  lastpic SLIME04
  tics 8
}

animation
{
  flat SLIME05
  lastpic SLIME08
  tics 8
}

[andrikpowell]

This is not actually an issue with EE persay, it's an issue with 200 Lines' EDF. It uses the Hexen format EDF animation to define its flats, which fires in a different function, always after P_UpdateSpecials. If you change it to a Doom format animation it will be synced. Below is the code of the fix that I sent to one of the authors. This was such a nightmare to hunt down.

Thanks sink666, this does fix the specific issue with "200 Line Massacre" on Eternity. I didn't actually realise there was a difference between Hexen and Doom format animations in EDF, or that they would function differently. Although in hindsight it does make sense.

It is worth noting the many major ports at this point do end up syncing flat animations with the first frame at the start of the map, and that currently Eternity Eternity is the only major Doom port that does not. This includes DSDA Doom, Woof-based ports (Woof, Nugget Doom, Doom Retro), and well ZDoom-based ports always had this behaviour implemented.

That is actually the main reason I had to redefine an animation EDF declaration in the first place. It was just to get Eternity to render the animation correctly. Ultimately it is up to you Eternity devs to decide what you want to do.

All I will say is that from a mapper's perspective, I'd rather have Eternity work with animations closer to all the other major ports to make it easier for mappers to do custom animations if they wish for them to be synced a particular way.

[sink666]

On further investigation, EE understands ANIMDEFS, and they get piped through the same function which the Hexen-style EDF animation does. EDF gets priority, but ANIMDEFS are not synced. Removing both the EDF and ANIMDEFS, the animations are synced as expected!

[andrikpowell]

On further investigation, EE understands ANIMDEFS, and they get piped through the same function which the Hexen-style EDF animation does. EDF gets priority, but ANIMDEFS are not synced. Removing both the EDF and ANIMDEFS, the animations are synced as expected!

Ah, this does seem to be the case. This is what I get trying to make a wad compatible for all major source ports :P

Unfortunately for "200 Line Massacre" I need to use both ANIMDEFS and EDF for it to work correctly. I use ANIMDEFS to force a certain texture in ZDoom ports for a vertical scrolling mikoportal wall to work right in MAP27. Luckily the doom format for EDF animation declaration will work just fine in this specific edge case.

I did not use ANIMATED because I didn't want it to affect other Doom-only ports. However it is worth bringing up that ZDoom-based ports and now DSDA Doom which have support for Hexen (and ANIMDEFS) have included a fix to restart animations at the start of the level, regardless of the animations being Hexen-style.

[sink666]

However it is worth bringing up that ZDoom-based ports and now DSDA Doom which have support for Hexen (and ANIMDEFS) have included a fix to restart animations at the start of the level, regardless of the animations being Hexen-style.

My latest PR addresses ANIMDEFS animations (which take priority over vanilla if present) and solves this issue as far as I can tell from my testing. Hopefully it gets accepted!