From b09998c534eaba1a931d97e8356afda00bfd20ed Mon Sep 17 00:00:00 2001 From: Jan Hohenheim Date: Mon, 14 Jul 2025 16:53:46 +0200 Subject: [PATCH] Fix duplicate sentence --- examples/movement/physics_in_fixed_timestep.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/examples/movement/physics_in_fixed_timestep.rs b/examples/movement/physics_in_fixed_timestep.rs index 4a0632ce9b..c2e9735c2a 100644 --- a/examples/movement/physics_in_fixed_timestep.rs +++ b/examples/movement/physics_in_fixed_timestep.rs @@ -55,8 +55,8 @@ //! One notable exception is the camera. Cameras should update as often as possible, or the player will very quickly //! notice choppy movement if it's only updated at the same rate as the physics simulation. So, we use a variable timestep for the camera, //! updating its transform every frame. The question now is which schedule to use. That depends on whether the camera data is required -//! for the physics simulation to run or not. For example, in 3D games, the camera rotation often determines which direction the player moves when pressing "W", -//! the camera data to run or not. For example, in 3D games, the camera rotation often determines which direction the player moves when pressing "W", +//! for the physics simulation to run or not. +//! For example, in 3D games, the camera rotation often determines which direction the player moves when pressing "W", //! so we need to rotate the camera *before* the fixed timestep. In contrast, the translation of the camera depends on what the physics simulation //! has calculated for the player's position. Therefore, we need to update the camera's translation *after* the fixed timestep. Fortunately, //! we can get smooth movement by simply using the interpolated player translation for the camera as well.