Different length of inner and outer diagonal for roads

[Leartin]

straight-up an old extension request of mine: https://forum.simutrans.com/index.php/topic,15200

This patch allows to set an offset for road vehicles between 0 (center) and 16 (edge) - default is 0.
When set, inner curves are shorter (have less steps), while outer curves are longer (have more steps) by the same amount. Therefore, road vehicles should look a lot smoother when they turn, especially in larger paksets.
Due to the datatype used, the outer curve can never be longer than a straight piece of road. Since most paksets use the 'new' default of ~ 180 steps on a diagonal, only ~70 steps are left, so even if you try to set the value 16, it won't be different from ~ 6. Though there is no reason to have your cars on edge anyway
I made certain this works with drive_on_left as well.

In order to have any change at all, copy "road_diagonal_offset=16" in the PAKSETS config file.
Naturally, the smaller the pakset, the less the effect. I don't think paksets <= 96 need to bother with it.

[prissi]

I certainly understand the motivation for this. But the proposed solution has two problems:

Passing a road tile can take now more time than passing a straight tile. This could lead to more traffic jams at each corner. (This was also my concern in 2016.) Moreover, trucks will be even ripped further apart or squeezed together at curves. These two things could be alleviated by altering also the speed accordingly.

As it is now this patch would totally remove the chance to go back to rotate just the viewport and leave the game engine straight (for rotating only the personal the view in network games.) However, since there was not much effort on that, it will probably not happen anyway soon.

Anyway, I think it would be better to keep the internal steps the same, so the time for a vehicle to pass a curved road tile stays the same as before. Instead apply a multiplier to the offset of the vehilce coordinates. (That would even allow for larger offsets), but only if the way below is a curve. (Otherwise the vehicles would periodically accelerate and brake on long diagonals).

[Leartin]

Passing a road tile can take now more time than passing a straight tile. This could lead to more traffic jams at each corner. (This was also my concern in 2016.)

Currently, diagonals are always shorter (unless defined otherwise in simuconf). A car passes through a curve faster than on a straight piece of road, that's visible behavior in the game. With the patch, AT MOST, a curve will take a car AS LONG as a straight tile, since it won't ever have more steps - 255 is the max. So why would it take more time to pass such a curve?

Code Select Expand

step_offset = (uint8) min(VEHICLE_STEPS_PER_TILE-diagonal_vehicle_steps_per_tile-1, (diagonal_vehicle_steps_per_tile * road_diagonal_offset)>>4);

Moreover, trucks will be even ripped further apart or squeezed together at curves.

The opposite is the case. Without this patch, a truck using an outer curve will be ripped apart, while a truck using an inner curve will be squeezed together, that's unavoidable. This patch evens things out, so there is less ripping and less squeezing.

As it is now this patch would totally remove the chance to go back to rotate just the viewport and leave the game engine straight (for rotating only the personal the view in network games.) However, since there was not much effort on that, it will probably not happen anyway soon.

Why would that be? Rotating doesn't affect whether you are on the outer or inner curve. A rotated viewport should behave exactly the same as an unrotated one in regards to this patch.

Anyway, I think it would be better to keep the internal steps the same, so the time for a vehicle to pass a curved road tile stays the same as before. Instead apply a multiplier to the offset of the vehilce coordinates. (That would even allow for larger offsets), but only if the way below is a curve. (Otherwise the vehicles would periodically accelerate and brake on long diagonals).

A terrible idea. What happens on an intersection? If you take an intersection as curve, then you will get the break-acc-cycle in a city that built along a diagonal road and turned it into a bunch of intersections. But if you take it as a diagonal, then only "pure" curves would change - that's not even worth it.

[prissi]

OK, you are right, entering (or exiting a curve) should no be a big problem (although vehicles deccelerate in curves, so making the distance longer makes it more likely to cause traffic jams due to no clearing the curve tile fast enough).

As it is now this patch would totally remove the chance to go back to rotate just the viewport and leave the game engine straight (for rotating only the personal the view in network games.) However, since there was not much effort on that, it will probably not happen anyway soon.

Why would that be? Rotating doesn't affect whether you are on the outer or inner curve. A rotated viewport should behave exactly the same as an unrotated one in regards to this patch.

If you rotate the viewport only, after a 90 degree rotation everything would look even worse if the behaviour is kept the same. The vehicles will change tiles according to no rotation, i.e. even more early and even later than normal. 18 woudl look ok again, I think.

Zitat von: prissi am Heute um 00:46
Moreover, trucks will be even ripped further apart or squeezed together at curves.
The opposite is the case. Without this patch, a truck using an outer curve will be ripped apart, while a truck using an inner curve will be squeezed together, that's unavoidable. This patch evens things out, so there is less ripping and less squeezing.

Maybe this was not clear enough: The trailer switches direction in this patch when the engine moved a smaller (inner) or longer (outer) tile distance as expected by the current alignment. Hence is will be pixelwise closer/further away. This distance will switch between driving on left and driving on right and hence cannot be compensated by realigning images in the pak. (Also the second trailer would need twice the offset.)

The turning itself looks nicer, I agree.

Zitat von: prissi am Heute um 00:46
Anyway, I think it would be better to keep the internal steps the same, so the time for a vehicle to pass a curved road tile stays the same as before. Instead apply a multiplier to the offset of the vehilce coordinates. (That would even allow for larger offsets), but only if the way below is a curve. (Otherwise the vehicles would periodically accelerate and brake on long diagonals).
A terrible idea. What happens on an intersection? If you take an intersection as curve, then you will get the break-acc-cycle in a city that built along a diagonal road and turned it into a bunch of intersections. But if you take it as a diagonal, then only "pure" curves would change - that's not even worth it.

Driving along long diagonals should not be a problem, if the objects are properly aligned (especially with a normal non-stretchy diagonal multiplier). Your patch does not change the total length of two diagonal tiles, at least for low enough multiplier. So driving along diagonal should not change, apart from the different distances between due to different distance due to the enter the tile as mentioned above. So the only problem are the curves.

I will play around with this more tonight.

[Leartin]

(although vehicles deccelerate in curves, so making the distance longer makes it more likely to cause traffic jams due to no clearing the curve tile fast enough).

I'm not sure that decceleration is enough to have an impact in a city (at least my test vehicles never showed that they get slower). Worst case, one could decrease the step count slightly to have ~10 steps buffer for the decceleration? (Or one does not choose a high value...)

The vehicles will change tiles according to no rotation, i.e. even more early and even later than normal.

Sorry, still don't see it - it doesn't matter if there is rotation or not, long side is long side, and takes longer, short side is short side and takes shorter. So if vehicles change tiles when they did the lowered step count of an inner curve in base rotation, they change at the correct time for all other rotations as well, since the vehicle completed all the steps for their (rotated) inner curve.

The trailer switches direction in this patch when the engine moved a smaller (inner) or longer (outer) tile distance as expected by the current alignment. Hence is will be pixelwise closer/further away. This distance will switch between driving on left and driving on right and hence cannot be compensated by realigning images in the pak. (Also the second trailer would need twice the offset.)

Why, yes, but thing is: The current alignment cannot be correct, since it was never possible to compensate for the difference in length between the inner and the outer curve. After all, the alignment has to work for bends in both directions. But this is too complicated for words, so let's use a graphic:

To the left is old behavior, to the right is patch behavior. The pink vertical lines mark the length of the diagonal tile. That is, currently both lanes have the same length, while my patch shortens and lengthens them.
On the vehicles, I marked with a yellow line where they are aligned for a bend. For this example, it only matters that it's consistent, in actuality it would also be defined by where the vehicle stops in halts - ignored for simplicity.
So as you can see, in the second row, both vehicles reached the end of tile. Therefore, they switch to the beginning of the new tile (row three). From there, they move on (how fast the diagonal moves compared to the straight is a different setting, so I ignored that for the example - but all vehicles on the same axis move the same amount of pixels.)

Changing the alignment in the graphics is basically moving where the yellow line is, where the vehicle bends. But as you can see: In the top vehicle, you'd want to close the gap, but in the bottom vehicle, you'd want to widen it.
Since we only look at the relationship between two directions, this is still doable - you can, for example, move the yellow line on the SW-vehicle to the left. However, it's exactly the same for the relationship between two directions all around. If I'd show the same example with SW and S instead of W and SW, you'd come to the same conclusion - move the yellow line in the S graphic closer to the tip of the vehicle. Go all around once, and comparing NW with W, you'll want to move the yellow line for the W graphic. But since you began here, adjusting SW to W, you are stuck in an endless cycle. Plus, any adjustment you make to compensate here will do the complete opposite for drive_on_left.
Essentially: It's impossible to align graphics properly, and this patch aims to fix that, rather than the other way around.

Though I admit - that hinges on the assumption that the trailer is always truck.length*16 steps behind the truck. If trailers are weirder than that, I wouldn't know what happens.

Your patch does not change the total length of two diagonal tiles, at least for low enough multiplier.

It never changes the length of two diagonal tiles. The amount of steps reduced in inner curves and the amount of steps added in outer curves is always the same.

[prissi]

The length of two diagonals is no longer the length of two tiles if clipping occurs. So clipping must be avoided.

But honestly, I have looked many times at pak128 vehicles at full zoom in and actually find the trailer movement nicer with =0. With pak192 the difference are again subtle so tiurns from north to NE are nice, but NE to east worse. (aasuming 0 means off and 16 mean largest effect)