From 7c239e5a50bc8c6d1b027fabeced1cbd2d95a58c Mon Sep 17 00:00:00 2001 From: Max Hilbrunner Date: Fri, 16 Jul 2021 13:15:53 +0200 Subject: [PATCH] Merge pull request #5094 from hpnrep6/canvas-layer Fix :ref: formatting in Canvas layers (cherry picked from commit 92ae59588840a7573cd5c87933508f568dcda8b9) # Conflicts: # tutorials/2d/canvas_layers.rst --- tutorials/2d/canvas_layers.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tutorials/2d/canvas_layers.rst b/tutorials/2d/canvas_layers.rst index 38a005c1d..cd41fa474 100644 --- a/tutorials/2d/canvas_layers.rst +++ b/tutorials/2d/canvas_layers.rst @@ -26,11 +26,11 @@ Effects like scrolling are best achieved by manipulating the canvas transform pr efficient than moving the root canvas item (and hence the whole scene). Usually though, we don't want *everything* in the game or app to be subject to the canvas -transform. Examples of this are: +transform. For example: - **Parallax Backgrounds**: Backgrounds that move slower than the rest of the stage. -- **UI**: Think of a user interface (UI) or Heads-up display (HUD) superimposed on our view of the game world. We want a life counter, score display and other elements to retain their screen positions even when our view of the game world is changing. +- **UI**: Think of a user interface (UI) or head-up display (HUD) superimposed on our view of the game world. We want a life counter, score display and other elements to retain their screen positions even when our view of the game world changes. - **Transitions**: We may want visual effects used for transitions (fades, blends) to remain at a fixed screen location. How can these problems be solved in a single scene tree?