Scroller inconsistencies >:@

[Tristan]

Hi! I'm a silly bastard who likes abusing conveyor belts and flinging stuff about with them. They are an underappreciated feature imo, but it's not hard to see why, when it can be difficult to get them to even behave themselves in the first place.

I've always been aware that scrolling floors (line action 252) don't behave consistently between PrBoom+ and GZDoom, but the magnitude of inconsistency was quite unknown to me before today. So, what's up with this shit? Is there anything mappers can do to optimise consistency between the two ports? Here's some stuff I have questions about.

 

1) Speed

I've been under the impression that scrollers are slower in GZDoom than in PrBoom+, though it seems that past a certain point that couldn't be any more false. Here's a test launch I whipped up:

 

Quite simple, when you pass the red torches at the top of the ramp, you will be flung towards the target. The target's centre is 4736 units from the end of the ramp. It's a long shot, for sure, but with a long enough line to set the scroller speed, we shouldn't have a problem right? So, the scroller is 10240 long, with an angle of exactly 90°. While running forward (and only forward, not SR40 or 50), let's see where GZDoom 3.3.2 lands us.

 

Not bad! The target has a diamater of 384 units, so to land on it at all can be considered a success. Overshooting isn't a problem, we can always put crash barriers behind it, it would be an undershoot that really blows. So, PrBoom+ 2.5.1.4, I'm expecting to need those crash barriers, as it should launch me a lot further than I want. -complevel is 11, though I don't think cl 9 was any different.

 

 

Ouch. Good thing I built that crash barrier, because you can barely see the target from this far away. Even shortening the line to 1024 units (10% of its original length) yields this same result. Speed limits, booooo.

The same thing can be achieved in GZDoom if the "Enable Wallrunning" compatibility flag is enabled. Uh, what? This has nothing to do with wallrunning surely?

 

2) Direction

Let's put these launchers into practice - a real map.

PrBoom+ is about to ruin your day if you're doing this stuff at weird angles, and in a time where mappers like to use nothing other than weird angles, that's a bit problematic.

 

 

Here you see two consecutive launches - in both cases the red torches mark the launch point, and the blue torches are the destination - you can see the 2nd set of blue torches up towards the top left, that's a pretty big jump.

The first jump is roughly 150°, give or take a tiny amount depending on which point you step onto the launch platform.

 

 

The scroller is dictated by two lines, both of which are apparently somewhere between 149° and 150° - drawing over them will show the latter, hovering over them to show their properties will show the former. So basically they're more or less the same angle, 1° out at most, which isn't going to be a problem at this distance. Let's see how GZDoom does.

 

 

Perfect. Straight between the blue torches, coming to a rest roughly in the centre of the island. And now for PrBoom+

 

 

The X is where I wanted to land, and sometimes Pr+ will do this, but it depends on how you approach the launch pad. In the above shot, I've been launched somewhat to the right, bouncing off the torch and into the waters below. This various behaviour seems to be more consistent with a 145° vector, so PrBoom is rounding down apparently to the next lower multiple of 5°, ok.

 

So what about the next jump - it's 214/215°. GZDoom, of course, lands on target. PrBoom+ swings off to the left, somewhat towards 220°. Ok, so now we're rounding up to the next higher multiple of 10°, make your damn mind up Boom.

Another jump not pictured in earlier shots is a similar deal to my initial thing with the target, except this one has a vector of 3°.

Here, the speed and direction issue start to cause trouble - not only does Pr+ land about 800 units short, it sods off to the side with a vector of about 10°, so again rounding up to the nearest 10, leaving the first launch as an outlier, surely that should've rounded up from 149.6 or whatever to 150, and so would be always on target?

 

Any explanation as to what's going on here and if I can implement these better would be much appreciated.

 

EDIT: Whilst using Boom (strict) compatability in GZDoom *does* fuck up the distance element as mentioned above (due to the wallrunning flag), it should be noticed that the angle stays accurate.

Edited September 11, 2018 by Eris Falling

[Nine Inch Heels]

Basically any "highspeed scroller" is not going to give precise results in ZDoom derivative ports. The only speed that is consistent between both ports, to my knowledge, is with a 32mu long linedef and one that gets you to the highest speed the engine allows for (not 100% certain here though). Practically everything else will differ.

 

I think if you want for this to change, ask the GZDoom devs to get their stuff in line with how it originally was supposed to work. Aaaand good luck with that.

 

As for timers: If anybody wants timers to be consistent between PrBoom+ and GZDoom: Use raise ceiling at slow speeds to block and time the dolls. It will raise the ceiling at 35mu/sec in PrBoom+ and (G)ZDoom, meaning you can get practilly the exact same times for conveyors that you use for timed lock-ins and such.

 

 

This may be tangentially interesting:

 

[Tristan]

Heh, I've encountered "conveyor is too slow" in another map before, but it was ZDaemon that broke, not PrBoom+, oddly enough. In the case of what I'm doing in this thread though, I can't really put the ZDoom-derivatives at fault though, they're behaving as they should: If I point a scroller at 3°, I need it to scroll at 3°, not 10° :I

 

I guess the ideal scenario would be for PrBoom+ to have a more complete implementation of scrolling floors, however I understand this is outside of PrBoom+'s scope. Perhaps this is something we could have one day if that new port standard ever gets anywhere, as this is really something I'd like to see ironed out, and the Z-ports are already there... Just strikes me as weird that you need those ports to get the most out of Boom features :v

 

 

[Nine Inch Heels]

2 minutes ago, Eris Falling said:

I guess the ideal scenario would be for PrBoom+ to have a more complete implementation of scrolling floors, however I understand this is outside of PrBoom+'s scope. Perhaps this is something we could have one day if that new port standard ever gets anywhere, as this is really something I'd like to see ironed out, and the Z-ports are already there... Just strikes me as weird that you need those ports to get the most out of Boom features :v

I can launch stuff in PrBoom+ at practically every angle you could possibly want. It's when the player is involved, and things such as momentum can come to bear that you get some "rounding errors" in PrBoom+ as far as I am aware.

 

As for using ZDoom ports to get the most out of Boom features, don't count on that. Some Boom actions caused issues for GZDoom for a very long time, and I'm not even sure if "transfer sector properties" has been fixed by now or not.