Move frame prediction logic for camera from Sector to Camera#3173
Move frame prediction logic for camera from Sector to Camera#3173mstoeckl wants to merge 1 commit intoSuperTux:masterfrom
Conversation
da82dfb to
606b90b
Compare
|
I forgot to say why I am making this PR now: I spent a few hours today trying to figure out how to, when the frame prediction option is enabled, change the Camera logic to extrapolate the camera position instead of interpolating with between 0 and 1 frames of delay. (Done right, this should make the jump cuts when Tux goes through pipes in |
|
I tested this briefly. I think with this change it looks even smoother. |
606b90b to
3758735
Compare
Err.... when making this change I forgot to, as the code had done before, disable the camera interpolation when frame prediction is not used. (I've updated the commit to fix this.) The camera interpolation logic adds up to a frame of lag to the camera, so it's possible that you are just noticing the accidentally increased camera inaccuracy when frame prediction was off. This change should not affect how the frame prediction option works, except in the few rare cases where e.g. Camera.set_pos/Camera.set_scale are used in scripts. Edit: have pushed second update to adjust formatting. |
3758735 to
2b795fb
Compare
2b795fb to
566c7ed
Compare
566c7ed to
0c882f1
Compare
5083ab8 to
fdf2abb
Compare
fdf2abb to
0d074e6
Compare
|
Can this get merged? |
0d074e6 to
66ab4f3
Compare
66ab4f3 to
0d885aa
Compare
0d885aa to
9e73c4f
Compare
9e73c4f to
015e674
Compare
806ca6a to
c12b71b
Compare
This makes it possible to avoid interpolating the camera position when a Camera::move or other discontinuous transition is requested.
015e674 to
d75b5e3
Compare
This commit avoids interpolating the camera position when a Camera::move or other discontinuous transition is requested.
Note: jumps in the camera position that are purely driven by changes to Tux's position will continue to be interpolated. (For example, when
Tux.set_pos()is called inbonus1/mario.stl.)