[Bug] Desynced Flat Animations from Vanilla/Unity Port

[andrikpowell]

Background

Version of Chocolate Doom: 3.0.0 Stable

Operating System and version: Windows 11 21H2

Game: Doom 2

Any loaded WADs and mods (please include full command line):
-merge 200lnmv.wad -dehlump

Bug description

Observed behavior: flat animation is offset by one frame compared to Vanilla Doom / Unity Port.

Expected behavior: flat animation should be synced up to Vanilla Doom / Unity Port.

Ok this is a bit of a long one.

Let me start by how flat animations work in Vanilla 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.

Now what does Chocolate Doom do incorrectly?

In Vanilla Doom / Unity Port, the FF_START lump is counted in the lump order, whereas in Chocolate Doom, it is not. This will lead to flat animations desyncing because of how the flat animations work specifically with lump order.

Why is this an issue?

I have a map from an upcoming megawad that syncs the flat animations with the texture animations that works correctly in Vanilla Doom, but not Chocolate Doom. It has 6 frames for both the flat and the texture that go like this: Blue>Blue>Red>Red>Yellow>Yellow. They sync correctly in Vanilla Doom, but not Chocolate Doom, because of how Vanilla Doom considers FF_START as a flat coming before F_END.

How can you test?

200lnv.wad is a test for the megawad. MAP25 is the map that features the animated flat and textures. You can delete the FF_START lump at the beginning of the wad or leave it there, and the flat animation will never change in Chocolate Doom.

If you run the map in Vanilla (patched with 200lnv.deh) or in the unity port, you will see that either having FF_START or removing it, will in fact change the flat animation.

Explanation Video:
https://www.youtube.com/watch?v=co5h-fwx6Ho

Test WAD Download:
200 line massacre WIP

[rfomin]

It seems to work correctly if the -file option is used. I tested with this command:
chocolate-doom -file 200lnmv.wad -dehlump -warp 25

[andrikpowell]

It seems to work correctly if the -file option is used. I tested with this command: chocolate-doom -file 200lnmv.wad -dehlump -warp 25

Interestingly enough, you are correct. Using -file will work, but -merge will not.
Perhaps this is because "merging" the doom2.wad with 200lnv.wad together changes the lump order, therefore breaking the flat sync.

I will mention that in crispy doom, -file still does desync.

[fabiangreffrath]

I will mention that in crispy doom, -file still does desync.

That's because in Crispy Doom -file is actually -merge.

[andrikpowell]

I have found a way to sync up the flat animations both when using -file and -merge.

The solution became more clear to me, when I realised what the actual problem was:
I needed to find a way to shift the lump order after only a -merge.

When looking at a merged file (via DeuSF), I realised something.
When combining doom2.wad and 200lnmv.wad, the duplicate flats are omitted.

That gave me an idea: Add flats with the vanilla names into my wad after the animation frames to specifically offset the wad only after a merge. I just to make sure those replaced flats aren't used in the maps themeselves.

From the updated file below, my hack seemed to work:
200 line massacre WIP

Sadly I was hoping this would fix the flat desync in DSDA Doom and PrBoom, but it seems that those ports calculate flat animations differently than with a merge and file. Same with the old version of Woof (without the new flat desync code).