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

[andrikpowell]

Hey DSDA Doom team,

There's a certain effect that I'd like do have working in all ports, but it seems that DSDA Doom and PrBoom+ ports are not consistent with FLAT animations like Vanilla/Unity Port.

I also found that Chocolate and Crispy Doom also didn't sync them correctly. I submitted a bug report (chocolate-doom/chocolate-doom#1509), in that I found the reason for the desync in those ports. It has to do with the ports not including FF_START in 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 map i'm testing is here (MAP25):
200 Line Massacre
^ The flat and textures currently sync up with Vanilla / Unity Port / Eternity Engine.

I suggest this fix:
jeffdoggett/Doom@e2e0e69

Both Doom Retro and Woof have implemented this fix.
It basically forces animations to start from the first frame (similar to how ZDoom ports deal with animated textures and flats).

Here is a video showing the effect in the wad (This vid was made for the Chocolate Doom bug report):
https://www.youtube.com/watch?v=co5h-fwx6Ho

[kraflab]

So I can see that it's a simple fix, but this assumes that a wad was configured to work in vanilla. What about wads that were designed knowing the "wrong" behaviour and currently work only in the "bugged" ports? A behaviour that has been around for a long time in prboom+ has a strong chance of being the expected behaviour even if it doesn't match vanilla. I'm a bit hesitant then to change how it works. @rfomin @fabiangreffrath did you check this out with respect to woof?

[andrikpowell]

So I can see that it's a simple fix, but this assumes that a wad was configured to work in vanilla. What about wads that were designed knowing the "wrong" behaviour and currently work only in the "bugged" ports? A behaviour that has been around for a long time in prboom+ has a strong chance of being the expected behaviour even if it doesn't match vanilla. I'm a bit hesitant then to change how it works. @rfomin @fabiangreffrath did you check this out with respect to woof?

I can agree that maybe a compatibility setting should be added to allow for the old bugged way for PrBoom / DSDA Doom flat animations.

Perhaps I'd be fine with the flats only being synced on complevel 2. The actual problem is that the flat is desynced by 1 frame compared to Vanilla. I have not done rigorous testing of higher complevels.

It's important to note, however than the flat animations in DSDA Doom are desynced from even other ports like Woof. DSDA Doom flat animations are also desynced from Eternity and ZDoom ports. So wads that would be designed for this "bugged" behaviour would only work correctly solely in PrBoom / DSDA Doom and not correctly other ports. This is the reason why not many map makers have done this effect because of how different ports never synced flats the same.

I think that getting ports to be consistent in this behaviour would allow for more creativity in the map making department. I have put alot of work getting this effect to work correctly in Vanilla ports, since it is a Vanilla wad. Like always, I'm pushing the engine in ways that most do not.

I would like to mention that it was not actually FF_START in Chocolate / Crispy Doom that caused the flats to desync from Vanilla. It was actually the -merge command (-file in Crispy Doom is actually -merge). However, I have found to get the wad to both work by merging and file (Updated the link in last post). You can read my explanation here: chocolate-doom/chocolate-doom#1509

I've been trying to find a way to offset the flat sync in DSDA Doom / PrBoom locally in the wad itself... But I'm not sure how DSDA Doom deals with flats, or if it merges. I thought that perhaps the desync was caused by the -N0_TEX- flat included in dsda-doom.wad, but adding that to my wad had no effect on the flat sync, so I doubt that it merges since if it did that would indeed desync the flat a frame. All I know is that DSDA Doom is 1 frame offset from Vanilla / Eternity Engine. If there's some kind of trick I could do in the wad to get it working in DSDA Doom, I'd do it immediately.

[rfomin]

@rfomin @fabiangreffrath did you check this out with respect to woof?

No, I don't know any other WAD that rely on this behavior, probably there is not many of them for the reasons @andrikpowell points out.

[kraflab]

Did you make some change that gets around the issue? Just went to fix it today but the linked wad seems to sync correctly before any changes 😅

[kraflab]

Ah I found an old version where it's still messed up, all good

[kraflab]

d63bc13

[andrikpowell]

Did you make some change that gets around the issue? Just went to fix it today but the linked wad seems to sync correctly before any changes 😅

This is because I implemented the most jank setup of all time, just to get it temporarily working on DSDA Doom and PrBoom+.

Basically Vanilla ports will merge all the lumps with the same name, when determining lump order. (i.e. If you have two FF_START lumps), Vanilla ports will only consider the one lump and the next lump would be #2 instead of #3 like you would expect.

DSDA Doom and PrBoom+ will add duplicated lumps with the same name as separate entries. So if I have 5 FF_START lumps, the lump after is #6 in DSDA Doom, PrBoom+, whereas in vanilla the lump after well be read as #2 in the lump order.

To get the animations to be synced temporarily I added 6 FF_START lumps at the top of the WAD, to specifically fix the sync for DSDA Doom and PrBoom+.

I still think it's a good thing to fix to make it easier for map makers though. I'm just explaining why the most recent WAD worked correctly.