32 Wide ditches and finesine calculations

[Enjay]

This information may be of interest to some of the source port programmers.

Graham Jackson (of the Risen3D port) sent me a file (originally by Hawkwind) that demonstrated a difference in behaviour between vanilla Doom and ports such as Zdoom...

If you load up the linked file in Zdoom and walk forward, you will fall into the ditch. If you load it up in vanilla Doom2, you will not fall into the ditch but, rather, remain at floor level so that you can walk right up to the teleport. The only other port I have checked this in is Risen3D so I don't know what happens in other ports.

I posted about this on the Zdoom forum. Here is what some of the forum goers had to say on the matter:

Xaser wrote:
I think this has come up before a loooong time ago, and if my memory serves me correctly, the verdict was not to change it. 'Course, one should never trust the Xasermemory... ;)

As a "for the record", this 32-unit slip is only possible from start or from a teleport, since moving even slightly or turning will render you unable to squeeze through. It's indeed interesting that vanilla doesn't do it, though -- might be worth a compat option in that case, if it's deemed significant enough.

The only wad that intentionally uses it that I know offhand is Lost Soulsphere, which admittedly was only added because of the discussion at hand. That should give everyone an idea of how long ago it was. :P

Gez wrote:

As a "for the record", this 32-unit slip is only possible from start or from a teleport, since moving even slightly or turning will render you unable to squeeze through.

And that might be the reason why. For silly reasons that have to do with binary representation of angles and rounding up of numbers, you can't move straight in Doom. It's not possible to move straight up North or South (IIRC), you will deviate a tiny bit. Creaphis had some in-depths thread about this on Doomworld, explaining stuff about glides and what made them possible or not.

Randy wrote:
Oooohhhh... I suppose that could happen from fixing the finesine table so it's accurate, which I did well over 10 years ago. Doom's finesine table is about 1.25 degrees off, which means pretty much all directional calculations in Doom are about 1.25 degrees off. Rather than change the finesine table (since a floating point version, if it ever happens, would exhibit the same behavior), I'd probably go for shifting the teleporting and spawning angles slightly so that they're not perfect multiples of 45 degrees. Though I do feel weird about intentionally introducing errors...

Acting on the above, here is what Graham Jackson had to say on the matter of how he has addressed this in Risen3D.

Fall through fix (Graham Jackson October 2011):

Ports that pre-calculate the finesine table (Risen3D, GZDoom, ZDoom for example) rather than loading it from a table in the exe in order to slim the size of the exe down can, under rare circumstances, lead to the player falling into a lower sector defined by lines that are either horizontal or vertical and separated by 32 map units. In Risen3D it seemed the best option was to introduce a small error (the smallest possible is adequate) for angles of 0, 90, 180 and 270 degrees. As such I am grateful for forum comments indicating the reason for the difference in behaviour between Doom and ports that use more accurate values.

Five changes are needed because of the extension to the finesine table to allow it to be used for cosine values using a 90 degree offset. These emulate rounding errors contained in the original doom tables (which may have been deliberate). I decided not to option this as the vanishingly small scale of the error appears to make no noticeable difference, other than to the fall through issue, in practice. This means it is theoretically possible to still fall through when moving across these sort of sectors but this must surely be equally true in the original Doom engine. In practice the rarity of this has led map authors into believing that a separation of 32 map units is adequate to prevent fall through. Risen3D previously used a different solution but this led to other issues so this has now been stripped using instead, in the latest release v220-12, fiddle factors to the finesine table after it's been stuffed as follows;

// v220-12 emulate Doom bug caused by 'angle of direction' rounding errors
finesine[ 0] |= 1;
finesine[2048] |= 1;
finesine[4096] |= 1;
finesine[6144] |= 1;
finesine[8192] |= 1;

The changed fallThrough2.wad allows for testing in the four relevant directions using the keyboard's designated forward key (not the mouse). Tracking the player's movement in the automap shows there is no discernable deviation although the distances travelled are admittedly small. There is also a 32 square cell purely to test a) that the player can only enter it by teleporting into it and b) that the player can exit it freely having done so. This is also in line with Doom behaviour.

It may be considered that this change could be introduced into ZDoom etc. without worrying about optioning it. I hope this is of use.

I am also linking to the revised fallthrough map. I rebuilt the nodes because this had not been done (which was needed for vanilla Doom but not for Risen3D or ZDoom) and gave it a name that made it easier to load with Vanilla Doom2 so that people can compare behaviours if they like.

http://www.zen64060.zen.co.uk/fallthrough2.zip

I hope that is of use to someone.

[Grazza]

Yeah, this is essentially exactly the same as gliding dynamics. I demonstrated the possible 32-unit-fall-through trick in this post.

This is also the reason why some glides are piss simple in Zdoom, but very hard in vanilla. Example: STRAIN map07: just move directly backwards from the starting position. So eliminating the slight rounding error in the movement code makes quite a difference in a range of situations.

[RjY]

Maes had a good thread about this - it turns out the code to generate Doom's hardcoded fineangle and tantoangle tables is still in linuxdoom-1.10, but commented out.

[Creaphis]

This doesn't surprise me too much after some of what we were able to figure out but I never thought of falling into a gap as a potential speedrun trick before. I imagine that a "guideless slip" would be even more difficult than a guideless gap glide as the player's momentum would have to run out precisely when he's standing at a fractionless coordinate.

If that last sentence made any sense you've wasted far too much time here.

[Graf Zahl]

RjY said:

Maes had a good thread about this - it turns out the code to generate Doom's hardcoded fineangle and tantoangle tables is still in linuxdoom-1.10, but commented out.

Problem is, the precision error does have bad side effects, like voodoo dolls trailing off a conveyor belt in case a map runs for a very long time. I have seen that in some very rare occasions where the conveyor was not bordered by one-sided walls.

So fixing it is a valid concern for ports that allow more actor movement control by mappers.

[Grazza]

Graf Zahl said:

Problem is, the precision error does have bad side effects, like voodoo dolls trailing off a conveyor belt in case a map runs for a very long time.

Is this the issue referred to in the first entry in this list, meaning that Boom corrected the imprecision for the specific case of conveyor belts?