shithub: choc

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;