Add an option to display the path travalled by the local player

[Calinou]

This is useful to avoid getting lost on larger maps. This is inspired by a feature from Doom Retro.

The following situations have been tested:

• Playing and finishing a map (path is cleared on map change as expected).
• Dying and respawning (path is cleared as expected).
• Non-rotated and rotated automaps.
• Teleporting intentionally doesn't create a path between the start and end point to prevent long streaking lines from appearing on the automap.

Future ideas:

• Tint path depending on progression in map (such as kill count / number of monsters in map), so you know how recent a certain portion of the path is. This could also be based on game time, but I think it'd be preferable for existing path points to keep their color.
  • Maybe tint path depending on owned keys?
• Change detail level based on the default map zoom (which is relative to the map size), so that larger maps can show a longer path before hitting the path length limit (and smaller maps can show a more detailed path).
• Always create a point if the player has stopped (regardless of the distance from last point), so that the line doesn't appear disconnected from the player if the player stops moving.

Preview

Normal mode

Overlay mode

[inkoalawetrust]

Okay, I don't really know much about the automap code, but this seems and works fine code-wise. But I feel like the way to not draw path lines when the player teleports is kinda flawed. It does not account for short distance teleports, like say a teleporter that just transports you to the other side of a wall, and so lines are drawn between teleport positions anyway.

[MrRaveYard]

Cool. If I were you, I'd use int16_t to store the coordinates, since double seems like an overkill.

[Calinou]

It does not account for short distance teleports, like say a teleporter that just transports you to the other side of a wall, and so lines are drawn between teleport positions anyway.

I've set the distance threshold pretty high while testing. It can probably be decreased as even full-speed SR50 isn't quite close to this distance threshold (in terms of distance travelled per tick).

Edit: I've reduced the distance threshold for teleport detection from 300 to 100 units. I've tested Doom 2 MAP12 with compatflags 64 (Enable wall running) and can confirm that line is still drawn correctly when you wallrun and SR50 on the outer walls, even if you also keep firing rockets backwards to propel yourself at the same time.

If I were you, I'd use int16_t to store the coordinates, since double seems like an overkill.

There doesn't appear to be a built-in type for points with int16_t, and I'm not sure if I should introduce one here just for this feature. Also, large maps may have coordinates outside the [-32768; 32767] range. While fline_t could be used here for 32-bit integer coordinates, it will require a bunch of casting when drawing, so any performance gains may not be noticeable.

[inkoalawetrust]

It does not account for short distance teleports, like say a teleporter that just transports you to the other side of a wall, and so lines are drawn between teleport positions anyway.

I've set the distance threshold pretty high while testing. It can probably be decreased as even full-speed SR50 isn't quite close to this distance threshold (in terms of distance travelled per tick).

Edit: I've reduced the distance threshold for teleport detection from 300 to 100 units. I've tested Doom 2 MAP12 with compatflags 64 (Enable wall running) and can confirm that line is still drawn correctly when you wallrun and SR50 on the outer walls, even if you also keep firing rockets backwards to propel yourself at the same time.

Yeah that works a lot better, by the way, if you wanna test something involving player speed, I'd suggest using the turbo 255 command, since it's much faster than rocket jumping or wallrunning.

If I were you, I'd use int16_t to store the coordinates, since double seems like an overkill.

There doesn't appear to be a built-in type for points with int16_t, and I'm not sure if I should introduce one here just for this feature. Also, large maps may have coordinates outside the [-32768; 32767] range. While fline_t could be used here for 32-bit integer coordinates, it will require a bunch of casting when drawing, so any performance gains may not be noticeable.

That ain't happening, 65535x65535 map units is the maximum size limit for any Doom maps except for the ones in Sonic Robo Blast 2, where IIRC they doubled the map size limit

[madame-rachelle]

This is an interesting idea and I like it, but, I am not a fan of it doing a static distance check to see if it should break the lines.

Instead, what you should do is see if the delta distance between tics is greater than the player's velocity. This would be a much more reliable way to check for teleport shenanigans since - in some cases - velocity can be arbitrary. As a general rule, always whenever possible, avoid arbitrary static numbers, especially in a moddable engine.

[Calinou]

Instead, what you should do is see if the delta distance between tics is greater than the player's velocity. This would be a much more reliable way to check for teleport shenanigans since - in some cases - velocity can be arbitrary. As a general rule, always whenever possible, avoid arbitrary static numbers, especially in a moddable engine.

I've tried my hand at implementing this in a second commit (which also fixes a compilation warning related to signed type comparison). It works mostly OK from my testing. One issue is that bumping into a wall and backing up will cause the line to be missing one point:

PS: Doom E2M4 is a good place to test this code, as it has a teleport near the starting area.

[inkoalawetrust]

Any more progress or info on this PR?