Resize event width and height don't match stage.stageWidth and stage.height

[mrpenguin]

With the following function:
private function event_stage_resize(event:ResizeEvent):void {
trace(event.width + " " + this.stage.width + " " + this.stage.stageWidth);
}

I get completely different values for each. The event.width actually matches the stage width and height. I have no idea where the values come from for stage.width (it increases but doesn't actually match the size of the stage). The stage.stageWidth value never changes from its original value. This is an unexpected behavior. In Flash, the stage.stageWidth will always reflect the actual size of the stage.

[PrimaryFeather]

Hi!

This works a little different than how it does in Flash -- that needs clarification, I have to add more documentation on that one. However, here's a sample.

I've added a resize event listener just as you, but it outputs some more values.

private function onResize(event:ResizeEvent):void
{
    trace("--- onResize() ---");
    trace("event.width: " + event.width);
    trace("stage.width: " + stage.width);
    trace("stage.stageWidth: " + stage.stageWidth);
    trace("starling.viewPort.width: " + Starling.current.viewPort.width);
}

Now, when I resize the Flash Player, I get output like this:

--- onResize() ---
event.width: 447
stage.width: 336
stage.stageWidth: 320
starling.viewPort.width: 320
--- onResize() ---
event.width: 444
stage.width: 336
stage.stageWidth: 320
starling.viewPort.width: 320
--- onResize() ---
event.width: 442
stage.width: 336
stage.stageWidth: 320
starling.viewPort.width: 320

As you can see, only the "event.width" changes. Here's what the different properties mean in Starling:

event.width: the new width of the Flash Player
stage.width: the width of the content on the stage
stage.stageWidth: the width of the coordinate system of the stage. 
starling.viewPort.width: the width of the actually rendered pixels

So, when you catch a ResizeEvent, you get the new size of the player. Now you can choose what happens by modifying the viewPort size or the stage size (all those properties are writeable in Starling).

E.g.:

 // viewport gets bigger, stage scales with it -- no matter how ugly
 // it looks! ;-)
 private function onResize(event:ResizeEvent):void
 {
     Starling.current.viewPort = new Rectangle(0, 0,
         event.width, event.height);
 }

 // viewport gets bigger, stage stays as it is. User could move
 // elements around to make up for bigger screen size.
 private function onResize(event:ResizeEvent):void
 {
     Starling.current.viewPort = new Rectangle(0, 0,
         event.width, event.height);
     stage.stageWidth = event.width;
     stage.stageHeight = event.height;
 }

I hope that makes sense!

[mrpenguin]

Ok, I understand how it works. All those values are very useful but a bit unintuitive. I think more documentation is a great idea. Thanks for your help on this, so far I think the package is awesome.

[PrimaryFeather]

Thanks for the compliments!
Yeah, you're right: it's not obvious how this works, I'll definitely have to document this better!

The reasoning behind it: you can develop a game for several resolutions without having to deal with different coordinate systems. E.g. when you develop for the iPhone, you need to support 480x320 and 960x640 (non-retina and retina display). With the setup above, you can set the viewport to one of those resolutions -- depending on where your app is running -- but use a stage size of 480x320 for both of them.

[mrpenguin]

Oh sure, I get why it's useful. It's just that I've been making apps with liquid displays for years and it took me several hours to figure out, even with the user guide from Thibault. Of course maybe I'm just a little slow sometimes. I think that how similar you've made Starling to the regular Flash display framework is a double edged sword. It's great to carry over concepts that we all understand but when there's a variation it's a lot more confusing than it would've been otherwise. That's ok though, after working through a project or two it'll just be second nature and I'm sure we'll all wish the Flash framework worked the way Starling does. Again, I'm loving working with it. Thanks a lot for your effort on it.

--- On Sun, 11/20/11, Daniel Sperl reply@reply.github.com wrote:

From: Daniel Sperl reply@reply.github.com
Subject: Re: [Starling-Framework] Resize event width and height don't match stage.stageWidth and stage.height (#51)
To: "mrpenguin" sadcebu2003@yahoo.com
Date: Sunday, November 20, 2011, 4:37 AM

Thanks for the compliments!
Yeah, you're right: it's not obvious how this works, I'll definitely have to document this better!

The reasoning behind it: you can develop a game for several resolutions without having to deal with different coordinate systems. E.g. when you develop for the iPhone, you need to support 480x320 and 960x640 (non-retina and retina display). With the setup above, you can set the viewport to one of those resolutions -- depending on where your app is running -- but use a stage size of 480x320 for both of them.

---

Reply to this email directly or view it on GitHub:
#51 (comment)

[PrimaryFeather]

Mhm, I totally agree about the double edged sword ...! In those cases where Starling does differ, almost everyone will be a little puzzled at first.

Thanks for the nice words, that means a lot to me! :-)

[algotechnologies]

@PrimaryFeather I love you man. You saved my life :D Very nice tutorial (Y)

[PrimaryFeather]

Haha, thanks for the compliments! I'm glad to hear it helped you, as well! 😄

[algotechnologies]

Yes because it's different from native Flash api. But now I understand after your tutorial :) thanks