-
Notifications
You must be signed in to change notification settings - Fork 7.1k
Unexpected behavior of queued scene operations #5359
Description
Version
- Phaser Version: 3.24.1 / 3.50.0-beta.9
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 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.
class SceneA extends Phaser.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);
}
}
}
class SceneB extends Phaser.Scene {
constructor(){
super({key: 'sceneB', active: true});
}
create(){
this.add.text(10, 10, 'SceneB.');
}
}
var config = {
type: Phaser.AUTO,
width: 800,
height: 600,
backgroundColor: '#000000',
parent: 'phaser-example',
scene: [SceneA]
};
var game = new Phaser.Game(config);