Scroll Floor is slower in PRBoom+?

[SCF]

Hello. I'm trying to finish up my first real map, and I don't know a lot about the differences between source ports. I used GZDoom to test it during development, but just to see if there were any issues I tried to play it in PRBoom+ as well. What I ran into was that the behavior of a scrolling floor was different.

 

I have a corridor sector 512 units long with a player voodoo doll, and a linedef with the same tag as the sector and type 253 (scroll floor). The linedef has a length of 16 units, and according to the wiki that means entities should move along it at 0.5 units per second. At 35 frames per second, it should take about 30 seconds for the doll to reach the end of the corridor, and that's exactly what's happening in GZDoom. But in PRBoom+ the doll is moving way slower, maybe 1/4th of the speed. This ruins an encounter since the player would have to wait several minutes for a door to open.

 

What's the explanation for this? Is it an issue with the map or with my settings? If it's former, how can the map be made consistent between ports? And since I don't know what the most popular ports are, is this something I should be concerned about this?

 

 

[andrewj]

The Boom Reference document is quite clear how these "carry" scrollers should work, and GZDoom is following the specification fine it seems.

 

But PrBoom (and I presume BOOM itself) is not following its own spec, the code in T_Scroll is just adding a vector to the thing's momentum, a lazy way of moving a thing since it leaves it to P_XYMovement to actually do the move, and that function applies FRICTION, and since the movement rate is quite low (less than 1.0) the friction is dominating and the things are moving much slower than they should be.

 

So yeah, Boom is bugged here.

[Bauul]

I'm no voodoo conveyor belt expert, but yes, there's a difference between how GZDoom and how PRBoom+ calculates the velocity of objects on conveyor belts.

 

There are specific ways of getting them to align though - I believe using a control linedef of 32 units exactly matches between the two.  Other more experienced PRBoom+ mappers can advise more.

[Aurelius]

A good reference when making voodoo conveyors:

 

My own limited experiments have shown that in addition to using a 32 map unit long activator, any multiple of that seems to work quite nicely as well. But when using shorter activators than 32, things get less and less reliable, most likely due to the factors andrewj explained in his post. That's why for delays you should rather use rising ceilings as timers. Afaik with "Slow" speed, floors and ceilings move exactly 1 unit per tic, which means 35 map units of vertical movement equals one second of delay.

[traversd]

Try not to rely on how fast the scroller moves, use sector barriers (doors with ceiling into the floor) to determine delays.

[JadingTsunami]

Can you post the WAD or portion that is showing this behavior?

[SCF]

Thanks everyone for the responses!

 

4 hours ago, andrewj said:

The Boom Reference document is quite clear how these "carry" scrollers should work, and GZDoom is following the specification fine it seems.

 

But PrBoom (and I presume BOOM itself) is not following its own spec, the code in T_Scroll is just adding a vector to the thing's momentum, a lazy way of moving a thing since it leaves it to P_XYMovement to actually do the move, and that function applies FRICTION, and since the movement rate is quite low (less than 1.0) the friction is dominating and the things are moving much slower than they should be.

 

So yeah, Boom is bugged here.

 

Ah, interesting. Does that mean the difference due to friction is still there at higher scroll speed (and the friction just becomes less and less perceptible as the speed increases)? Or does it only happen at very low speeds? Because there seems to be a big difference between a scroll linedef of 16 units (way slower in boom) and 32 units (seems about the same).

 

7 hours ago, Bauul said:

I'm no voodoo conveyor belt expert, but yes, there's a difference between how GZDoom and how PRBoom+ calculates the velocity of objects on conveyor belts.

 

There are specific ways of getting them to align though - I believe using a control linedef of 32 units exactly matches between the two.  Other more experienced PRBoom+ mappers can advise more.

 

I tried spacing everything apart twice as much and increasing the scroll linedef to 32 units, and now the timing seems about the same in PrBoom+. So that seems to have solved the problem here! I also checked out out some other maps with similar contraptions, and it looks like none of them use scrollers shorter than 32 units.