You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a new scene is pending to be added on a given frame, all other scene operations queued for that frame (such as re-arranging or stopping existing scenes) will be postponed until the next frame.
This behavior seems intentional and is caused by a return statement in SceneManager#processQueue (removing that statement or calling processQueue twice from update fixes the example below). However, it seems very counter-intuitive and I can't find any obvious documentation for it. Additionally, the commit that caused it (123c8f8) doesn't seem directly related. This is why I'm wondering whether it's intended (and if it is, what it fixes) or whether it's an oversight.
Example Test Code
Click the screen to add a new scene (SceneB) and shut down the existing one (SceneA) at the same time. Because SceneB was added, SceneA won't shut down until the next frame. Thus, its update method will run even though this.scene.stop() was called during the previous frame. In this (highly contrived) case, the extra invocation of update causes an error.
classSceneAextendsPhaser.Scene{constructor(){super({key: 'sceneA',active: true});}create(){this.shuttingDown=false;this.add.text(10,10,'SceneA. Click to stop SceneA and add SceneB.');this.input.once('pointerup',()=>{this.shuttingDown=true;});}update(){if(this.shuttingDown){window.alert('SceneA shutting down.');this.scene.stop();this.scene.add('sceneB',SceneB);}}}classSceneBextendsPhaser.Scene{constructor(){super({key: 'sceneB',active: true});}create(){this.add.text(10,10,'SceneB.');}}varconfig={type: Phaser.AUTO,width: 800,height: 600,backgroundColor: '#000000',parent: 'phaser-example',scene: [SceneA]};vargame=newPhaser.Game(config);
The text was updated successfully, but these errors were encountered:
Thank you for submitting this issue. We have fixed this and the fix has been pushed to the master branch. It will be part of the next release. If you get time to build and test it for yourself we would appreciate that.
Version
Description
If a new scene is pending to be added on a given frame, all other scene operations queued for that frame (such as re-arranging or stopping existing scenes) will be postponed until the next frame.
This behavior seems intentional and is caused by a
return
statement inSceneManager#processQueue
(removing that statement or callingprocessQueue
twice fromupdate
fixes the example below). However, it seems very counter-intuitive and I can't find any obvious documentation for it. Additionally, the commit that caused it (123c8f8) doesn't seem directly related. This is why I'm wondering whether it's intended (and if it is, what it fixes) or whether it's an oversight.Example Test Code
Click the screen to add a new scene (
SceneB
) and shut down the existing one (SceneA
) at the same time. BecauseSceneB
was added,SceneA
won't shut down until the next frame. Thus, itsupdate
method will run even thoughthis.scene.stop()
was called during the previous frame. In this (highly contrived) case, the extra invocation ofupdate
causes an error.The text was updated successfully, but these errors were encountered: