Flaky Friction

[Ed the Bat]

This has been a question in the back of my mind for a long time now. When using Sector_SetFriction, the Wiki claims that 128 returns a sector's friction to normal. However, I'm seeing that even then, floors are still slightly slippery, and players will even bounce a little bit off of walls and make their *grunt sound. Is the Wiki incorrect about what value the default is? Or is there something wrong with how the function is setting the friction? If anyone has any more information to satisfy my curiosities, I'd be quite grateful.

[Ed the Bat]

I was just looking over the source code for P_SetSectorFriction. Does anyone see anything obvious that might be causing this problem?

Code: Select all

void P_SetSectorFriction (int tag, int amount, bool alterFlag)
{
	int s;
	fixed_t friction, movefactor;

	// An amount of 100 should result in a friction of
	// ORIG_FRICTION (0xE800)
	friction = (0x1EB8*amount)/0x80 + 0xD001;

	// killough 8/28/98: prevent odd situations
	if (friction > FRACUNIT)
		friction = FRACUNIT;
	if (friction < 0)
		friction = 0;

	// The following check might seem odd. At the time of movement,
	// the move distance is multiplied by 'friction/0x10000', so a
	// higher friction value actually means 'less friction'.

	// [RH] Twiddled these values so that velocity on ice (with
	//		friction 0xf900) is the same as in Heretic/Hexen.
	if (friction >= ORIG_FRICTION)	// ice
//		movefactor = ((0x10092 - friction)*(0x70))/0x158;
		movefactor = ((0x10092 - friction) * 1024) / 4352 + 568;
	else
		movefactor = ((friction - 0xDB34)*(0xA))/0x80;

	// killough 8/28/98: prevent odd situations
	if (movefactor < 32)
		movefactor = 32;

	for (s = -1; (s = P_FindSectorFromTag (tag,s)) >= 0; )
	{
		// killough 8/28/98:
		//
		// Instead of spawning thinkers, which are slow and expensive,
		// modify the sector's own friction values. Friction should be
		// a property of sectors, not objects which reside inside them.
		// Original code scanned every object in every friction sector
		// on every tic, adjusting its friction, putting unnecessary
		// drag on CPU. New code adjusts friction of sector only once
		// at level startup, and then uses this friction value.

		sectors[s].friction = friction;
		sectors[s].movefactor = movefactor;
		if (alterFlag)
		{
			// When used inside a script, the sectors' friction flags
			// can be enabled and disabled at will.
			if (friction == ORIG_FRICTION)
			{
				sectors[s].special &= ~FRICTION_MASK;
			}
			else
			{
				sectors[s].special |= FRICTION_MASK;
			}
		}
	}
}

[Nightfall]

friction = 1.0 = 65536
=> 65536 = (0x1EB8*amount)/0x80 + 0xD001
=> 65536 = (7864 * amount) / 127 + 53249
=> 12287 = (7864 * amount) / 127
=> 1560449 = 7864 * amount
=> 198 = amount

So basically a value of 198 would imply normal friction?

[Ed the Bat]

Well, it wouldn't be the first time the wiki was wrong.
On a related note, I stumbled across this bit of now-ancient changelog:

February 27, 1999
- Note: Hexen's friction is roughly equivalent to a Sector_SetFriction of
171 (ends up as 0xf909, Hexen uses 0xf900). Player movement thrust should
be halved at this level. Changed the calculation of sector->movefactor
accordingly. (With the BOOM code, player thrust was nearly one fourth
normal with that level of friction.)
- Discovered that MBF's code to affect monsters with friction doesn't
work without the change it made to how mobjs are linked into the blockmap.

If 198 is standard, then Hexen's 171 would be below normal, AKA slightly more friction than Doom. I can certainly buy that as true.

[Nightfall]

1560449 / 7864 isn't even divisible, the real answer is 198.42943, but I guess you can't use that since it's expecting integers.

Well, I corrected the wiki page for it. I wonder, is this intentional or an error on the formula?

[Ed the Bat]

Ha, yep. With only 255 possible values to put in, I guess we'll just have to play close-enoughs. Still, maybe now I can update Reelism's scripts to stop the grunting and bouncing off of walls after resetting floor friction to normal.

Thanks a bunch for the help!

[randi]

The answer to your question is right here in this comment in the code:

Code: Select all

    // An amount of 100 should result in a friction of
    // ORIG_FRICTION (0xE800)   

friction = 1.0 = 65536
...
So basically a value of 198 would imply normal friction?

A friction value of 65536 or 1.0 would mean you lose no velocity due to friction, so no.

[Ed the Bat]

So neither 128 nor 198 are normal friction levels?

[randi]

An amount of 100 should result in a friction of ORIG_FRICTION (0xE800)

An amount of 100

100

[Ed the Bat]

Forgive me, I'm pretty much sourcecode-illiterate, otherwise I wouldn't have been puzzling on this for seven months.
Just wanted to be sure I understood which resources had so-far steered me wrong.

[Gez]

Nightfall's first mistake is that ORIG_FRICTION isn't 65536, but 59392 (0xE800.)
His second mistake is that 0x80 isn't 127 but 128 (c'm'on, even numbers don't become odd).

friction = 59392
=> 59392 = (0x1EB8*amount)/0x80 + 0xD001
=> 59392 = (7864 * amount) / 128 + 53249
=> 6143 = (7864 * amount) / 128
=> 786304 = 7864 * amount
=> 99.98779... = amount

If you go the other way around:
100 * 7864 = 786400
/ 128 = 6143.75 (int) => 6143
+ 53249 = 59392

[Nightfall]

Ouch. I guess this is what you get for doing math at 3AM.