Enjay
ASK ME ABOUT FOOTBALL / STEAM / DEAD CELEBRITIES / THE BLAIR WITCH PROJECT
Posts: 5596
Registered: 12-00 |
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.
|
10-03-11 18:02 
