Let's talk about damping
Added 2017-07-27 23:16:35 +0000 UTCNo, not dampening. Not that I would EVER make that typo. Repeatedly. Ahem.
The basic issue is, I wanted springs, but, I didn't want to use an actual spring equation. It needed to be more controllable. It turns out this has Issues. Namely, damping.
Meet Exhibit A. This contains two iterations of my attempts. Pretend those commented out bits aren't commented out for attempt #1. The basic idea here is that I want to flatten any velocity pointed in the total wrong direction immediately, and then gradually dampen any remaining velocity to get a nice, controllable spring.
Fortunately, this worked great! Unfortunately... it only worked on my computer. Because that isn't actually applying damping in a way that remains consistent if framerate changes. It's a complicated mess, but suffices to say, I'd get springing that worked great on my machine, but worked terribly on my partner's, and it was all down to there being no easy means of applying continuous damping in a frame-stepped way. That just... isn't a thing, that's WHY the spring equation involves use of exp() and so on. So I tried commenting it out as seen above, to see if that would work (nope that made it worse).
Then I tried this (also nope!), and I even tried making it fixed-frame! EVEN THAT DIDN'T WORK. It turns out, this whole area is a nightmare zone of math, and there's a very, very good reason why spring equations are what they are.
So, enter the alternative:
This is a way of doing something similar, suggested to me by @daisyowl and @TrinketTom on twitter. Full breakdown can be found here: http://www.rorydriscoll.com/2016/03/07/frame-rate-independent-damping-using-lerp/
Does that work for a ton of people? Yes! Read it, try it, grok it. Ask them if you don't understand it, though, because... I didn't use it.
I made something else. Which thus becomes this month's $3+ code tier post, since hey, it's neat code! That being said, the above is neat too, so check it out!
