Projectile smooth movement

[Doubleumc]

About the pull request

Changes the projectile's visual position to animate() across its projected path, providing smoother visuals, especially at higher client framerates.

Black squares: tiles actually traversed by the projectile object
Red line: visual path taken by the projectile
Purple marks: equidistant marks corresponding to number of traversed tiles (black squares)
Blue marks: closest points to center of traversed tiles (black squares)

The projectile's physical path (black squares) is unchanged. The system calculates how far along the physical path the projectile has travelled, draws a line from the start point to the end point (red line), then interpolates where along that line corresponds to that distance travelled (purple marks). This is slightly less accurate to the projectile's physical position than the closest point of the line (blue marks), but this slight potential offset is preferred for its smoother visuals.

This does not touch any code that actually effects the bullet's trajectory, this is purely cosmetic.

Tested:

• handheld guns
• scatter
• in-turf targeting (as visually consistent as the current implementation, at least)
• rockets
• plasma caster
• xeno spit

Explain why it's good for the game

Smoother apparent movement for projectiles gives a more appealing look.

Testing Photographs and Procedure

Screenshots & Videos

https://streamable.com/h6esir

Changelog

🆑
code: projectiles smoothly animate their movement
/:cl:

[Nanu308]

Just a question, would this have any performance impact at all?

[fira]

THANK YOU SO MUCH i tried to get this right several times when rewriting bullet travel but I simply couldn't manage to and gave up

An undesirable side effect of this is that instead of skimming walls the bullets will cut through corners but i'm hoping this is visually acceptable

Did you test this with M2C too? With current botched system the M2C bullets have an erratic trajectory for some reason, i suspect something is different with it

This probably has some performance impact clientside but given it's only translating with pixel_x/y and there's no transforms at work I'd think it's nothing major

[Doubleumc]

Just a question, would this have any performance impact at all?

Yes, but to what degree I don't know. There's the math, and the animate(). The math is basically a wash, as it does more operations but only once at the end of movement, instead of for every tile of movement. Its simple arithmetic in either case, nothing fancy.

The animate() is the elephant in the room. I understand this is a heavier operation, but to what degree I don't have the experience to say. I'll defer to those more knowledgeable than me.

TGMC, for instance, probably knows a thing or two. They also use an animate() for projectiles under certain circumstances, and had this to say about it:

Changing the vars through animation alone takes almost 5 times the CPU than setting them directly.
https://github.com/tgstation/TerraGov-Marine-Corps/blob/master/code/modules/projectiles/projectile.dm#L571

Lummox, the BYOND dev, also knows a thing or two. In a thread suggesting the same thing as TGMC's comment, he disagreed:

animate() will basically take the same amount of work as setting all those vars at once, but with small overhead
https://www.byond.com/forum/post/1897218#comment15961196

Whether the performance tradeoff is acceptable is something that can only be answered by large-scale testing.

[fira]

I don't think there's going to be any problem performance wise but I really want to see it at work live and ensure it still works well under server load

[Doubleumc]

An undesirable side effect of this is that instead of skimming walls the bullets will cut through corners but i'm hoping this is visually acceptable

The quirks of tile-based projectile movement will definitely be more visible as the animation lets you see the whole path. As you said in your original implementation #1608 "Smoother, more visual feedback (perhaps to a fault, as it shows how goofy our system is)"
This is the worst possible case, going from halfway point to halfway point:

Did you test this with M2C too? With current botched system the M2C bullets have an erratic trajectory for some reason, i suspect something is different with it

I didn't think to try these before but just did. Bullets come out and go in straight lines.

[fira]

Works fine in TM. There is a slight discrepancy in low angle trajectories as the bullet skims despite being angled, but it's still way better than it used to be

[Doubleumc]

Works fine in TM. There is a slight discrepancy in low angle trajectories as the bullet skims despite being angled, but it's still way better than it used to be

Could you elaborate on what you mean by this?

[fira]

Works fine in TM. There is a slight discrepancy in low angle trajectories as the bullet skims despite being angled, but it's still way better than it used to be

Could you elaborate on what you mean by this?

I'm not 100% sure but from what I've seen (which was a thing with normal system but i think due to my math being off) some bullets appear especially in low angle trajectories to keep skimming with the angle not being on par with the actual traveling trajectory

It could be something i've just imagined, haven't seen it happen much and bullets fly pretty fast

[zzzmike]

Is it possible that this is causing really weird disabler issues? I've been noticing disabler shots disappearing and having odd movements a lot more than before this was TM'd. Here's a video, I can't be sure it's a bug or not, but wanted to share https://www.youtube.com/watch?v=ObALzeO-xIo&ab_channel=MK

[Doubleumc]

The starting position of the bullets is incorrect with this PR resulting in bullets starting from behind your mob:

Thanks for letting me know! Starting in the firer's turf is as-per the movement code, but it visually appearing there is definitely unintended.

Is it possible that this is causing really weird disabler issues? I've been noticing disabler shots disappearing and having odd movements a lot more than before this was TM'd. Here's a video, I can't be sure it's a bug or not, but wanted to share https://www.youtube.com/watch?v=ObALzeO-xIo&ab_channel=MK

Is definitely possible its causing the odd movements. Or more accurately, its making the odd movements noticeable. The underlying movement code is untouched, its just the visuals that were changed. I'll look into smoothing out those doglegs.

[Doubleumc]

Projectile visuals will no longer overlap the firer. Projectile starts transparent and will fade-in based on distance travelled.

Projectile visual path now avoids doglegs. By necessity this slightly decouples the visual path from the real path, so corner-cutting may be slightly more noticeable.