diff options
| author | pancelor <pancelor@gmail.com> | 2024-03-12 22:10:38 -0700 |
|---|---|---|
| committer | Andrew Kelley <andrew@ziglang.org> | 2024-03-13 18:35:07 -0700 |
| commit | 7a858257f2c05f0ab8df0debda9f1d58b5ecf251 (patch) | |
| tree | fd97c46a20905ce449c5ef6f99931a9974ba995f /src/codegen | |
| parent | ea8e9e668b8b566a94e8d69476d392458918382a (diff) | |
| download | zig-7a858257f2c05f0ab8df0debda9f1d58b5ecf251.tar.gz zig-7a858257f2c05f0ab8df0debda9f1d58b5ecf251.zip | |
remove `math.lerp` bounds for t
I think of lerp() as a way to change coordinate systems, essentially
remapping the input numberline onto a shifted+rescaled numberline. In
my mind the full numberline is remapped, not just the 0-1 segment.
An example of how this is useful: in a game, you can write:
`myPos = lerp(pos0, pos1, easeOutBack(u))`
for some `u` that changes from 0 to 1 over time.
(see https://easings.net/#easeOutBack)
This will animate `myPos` between `pos0` and `pos1`, overshooting the
goal position `pos1` in a nicely-animated way.
`easeOutBack(float)->float` is a pure function that overshoots 1,
and by combining it with `lerp()` we can remap coordinates in other
coordinate systems, making them overshoot in the same way.
However, this overshooting is only possible because `easeOutBack(t)`
sometimes exceeds the range 0-1 (e.g. `easeOutBack(0.5)` is 1.0877),
which is not allowed by the current `math.lerp` implementation.
This commit removes the asserts that prevented this use-case. Now, any
value can be inputted for t. For example, `lerp(10,20, 2.0)` will now
return 30, instead of throwing an assert error.
Diffstat (limited to 'src/codegen')
0 files changed, 0 insertions, 0 deletions
