ref: 355e1d8d1d9935dbf902d81d53e410a5308045e4
parent: ceae5a1dc16c5f4a7a331ea33e71a21bbb215cd6
author: Fabian Greffrath <fabian@greffrath.com>
date: Mon Feb 18 07:33:55 EST 2019
doom: fix initialization value of floor->crush in EV_BuildStairs() (#1137) * doom: fix initialization value of floor->crush in EV_BuildStairs() Dammit! I think I have made a mistake when I added initialization for the floor->type and floor->crush fields in EV_BuildStairs() in commit 12b7676e7deb1e290be5128137014523227750a8. I was under the assumption that, because `10 != false`, it means the same as `true` -- but this is wrong. The code in question explicitly checks for `(floor->crush == true)` and not merely `(floor->crush)`, i.e. its value being unequal to zero. This will have lead to a desyncing TNT demo reported in https://www.doomworld.com/forum/topic/55558-final-doom-demos-complevel-4/?do=findComment&comment=1961738 I need an extra pair of eyes this time. Guys, please double-check against the code in PrBoom+. The relevant piece of code starts here: https://github.com/coelckers/prboom-plus/blob/master/prboom2/src/p_floor.c#L797 * add e6y's original comments to the initialization code
--- a/src/doom/p_floor.c
+++ b/src/doom/p_floor.c
@@ -30,6 +30,8 @@
// Data.
#include "sounds.h"
+//e6y
+#define STAIRS_UNINITIALIZED_CRUSH_FIELD_VALUE 10
//
// FLOORS
@@ -495,7 +497,10 @@
floor->floordestheight = height;
// Initialize
floor->type = lowerFloor;
- floor->crush = true;
+ // e6y
+ // Uninitialized crush field will not be equal to 0 or 1 (true)
+ // with high probability. So, initialize it with any other value
+ floor->crush = STAIRS_UNINITIALIZED_CRUSH_FIELD_VALUE;
texture = sec->floorpic;
@@ -541,7 +546,10 @@
floor->floordestheight = height;
// Initialize
floor->type = lowerFloor;
- floor->crush = true;
+ // e6y
+ // Uninitialized crush field will not be equal to 0 or 1 (true)
+ // with high probability. So, initialize it with any other value
+ floor->crush = STAIRS_UNINITIALIZED_CRUSH_FIELD_VALUE;
ok = 1;
break;
}