summaryrefslogtreecommitdiff
path: root/starling
diff options
context:
space:
mode:
Diffstat (limited to 'starling')
-rw-r--r--starling/node-2d.scm19
1 files changed, 17 insertions, 2 deletions
diff --git a/starling/node-2d.scm b/starling/node-2d.scm
index 095c5ca..9a18284 100644
--- a/starling/node-2d.scm
+++ b/starling/node-2d.scm
@@ -284,9 +284,24 @@
(move-by node dx dy duration smoothstep))
(define-method (teleport (node <node-2d>) x y)
- (move-to node x y)
+ ;; When teleporting, we want to avoid position interpolation and odd
+ ;; looking camera jumps. Interpolation is avoided by setting all 3
+ ;; position vectors to the same values. This prevents a visual
+ ;; artifact where the player sees 1 frame where the node is
+ ;; somewhere in between its former position and the new position.
+ ;; The camera jump problem occurs when a camera has a node as its
+ ;; tracking target and that node teleports. Normally, the camera's
+ ;; view matrix is updated before any nodes are rendered, and thus
+ ;; *before* the node can recompute its world matrix based on the new
+ ;; position. This creates 1 frame where the camera is improperly
+ ;; positioned at the target's old location. This 1 frame lag is not
+ ;; an issue during normal movement, but when teleporting it causes a
+ ;; noticably unsmooth blip. Forcing the matrices to be recomputed
+ ;; immediately solves this issue.
+ (set-vec2! (position node) x y)
(set-vec2! (last-position node) x y)
- (set-vec2! (render-position node) x y))
+ (set-vec2! (render-position node) x y)
+ (compute-matrices! node))
(define-method (rotate-to (node <node-2d>) theta)
(set! (rotation node) theta)