Gamua / Starling-Framework

The Cross Platform Game Engine
http://www.starling-framework.org
Other
2.87k stars 826 forks source link

Browser zoom scaling problem after reload #324

Closed kojot1234 closed 8 years ago

kojot1234 commented 11 years ago

When scaling the page up (100% and above) without listening to any resize events, the swf content holds the correct scale and isn't scaled up or down. However if the browser zoom level is set to below 100%, and then the project is loaded (or refreshed), the content becomes scaled up. Problem with mClippedViewPort occurs because mNativeStage.stageWidth and mNativeStage.stageHeight are different from the original viewport dimensions. Te touch listeners are in the right spots though. Replacing mClippedViewPort with current mViewPort size fixes the problem, but this probably isn't the right solution to this issue.

Stalring.as - Line 435: mClippedViewPort = mViewPort.intersection( new Rectangle(0, 0, mNativeStage.stageWidth, mNativeStage.stageHeight)); // incorrect scale

//mClippedViewPort = mViewPort; // correct scale

PrimaryFeather commented 11 years ago

Sorry for the late reply!

In which browser and FP version did you test this? I just tried it on OS X in Safari, Firefox and Chrome with FP 11.7 -- and it seemed to work just fine!

kojot1234 commented 11 years ago

It was happening across all browsers (FF,Chrome and IE with latest version of FF), I'm still investigating. I use two starling layers and one Alternativa3D. I am stripping the project to the minimum to find out what is going on. It looks like setting the (Alernativa3D) Camera3D.view.width and Camera3D.view.height has something to do with it. I'll keep you updated.

Damian

kojot1234 commented 11 years ago

Here's what I found. It may be an Alternativa3D issue, not Starling after all but I'm not sure. Although I don't have too much time to dig deeper into the framework. If the same viewport(Rectangle) is set first in Starling and then in Alternativa3D and the browser window zoom level is set to less than 100%, Starling viewport becomes larger than it should, but the touch listeners are in the correct places.

The way I solved it is by initially forcing Starling viewport to be the original and desired app size (1024x768). Applying re-sized viewport to alternativa3d and then setting the same original viewport to Starling.

Util.appWidth = 1024; // constant value Util.appHeight = 768; // constant value

var _w:int = (Util.appWidth * Util.defaultUIScale); // Util.defaultUIScale for correct scale with retina display var _h:int = (Util.appHeight * Util.defaultUIScale);

viewPort = new Rectangle(0, 0, _w, _h); // Global viewport

mStarling_top = new Starling(StarlingTop, stage, viewPort, stage.stage3Ds[0]); mStarling_bottom = new Starling(StarlingBottom, stage, viewPort, stage.stage3Ds[0]);

//then after creating the Alternativa3D View with same viewport camera.view = new View(viewPort.width, viewPort.height);

// run a function to check for correct viewport sizing and reapply

var _orginalViewport = viewPort; // store original viewport

var _w:int = Math.min(stage.stageWidth, (Util.appWidth * Util.defaultUIScale)); var _h:int = Math.min(stage.stageHeight, (Util.appHeight * Util.defaultUIScale));

viewPort = new Rectangle(0, 0, _w, _h); // set new smaller viewport

camera.view.width = _viewPort.width; // set cropped viewport for alternativa3d camera.view.height = _viewPort.height;

viewPort = _orginalViewport; // reapply stored viewport, Starling correct viewport.

starlingBottom.stage.stageWidth = viewPort.width; starlingBottom.stage.stageHeight = viewPort.height; starlingTop.stage.stageWidth = viewPort.width; starlingTop.stage.stageHeight = viewPort.height;

I don't know if that is of any use to you, or if it helps or explains the problem. Thanks for an awesome framework Daniel.

Damian

kojot1234 commented 11 years ago

Actually I just noticed I had that line in Staling.as so I did not solve it. "mClippedViewPort = mViewPort;"

ghost commented 11 years ago

I've been fighting with a similar problem for a while, not sure if it's related or not, but here's what I've figured out.

I'm developing on Linux, and maybe due to my window manager, or the old version of the standalone flash player I'm running, the window goes through several size changes as it's appearing, and there's some time sensitive stuff that sometimes messes up my stage.

It seems to be because updateViewPort() in Starling.as only recalculates mClippedViewPort if the viewport size changes, and not if the native stage size changes, even though it is derived from both. The two situations that I run into are:

Situation 1: Native stage resize event #1 occurs Native stage resize event #2 occurs I initialize Starling with a viewport of 1024x768, and everything is fine.

Situation 2: Native stage resize event #1 occurs I initialize Starling with a viewport of 1024x768. Native stage resize event #2 occurs, I set the viewport to 1024x768 on the Starling instance, but the clipped viewport is not recalculated because although the stage size has changed, the viewport remains the same as I set it when I initialized Starling.

So far, my solution has been just to do the following after I get a native stage resize event: _starling.supportHighResolutions=!_starling.supportHighResolutions; _starling.supportHighResolutions=!_starling.supportHighResolutions;

Setting supportHighResolutions causes Starling to call updateViewPort(true), which recalculates mClippedViewPort, and it seems to solve any problems I was having.

PrimaryFeather commented 11 years ago

Thanks a lot for the information, and for providing a fix as well. That's interesting!

Damian, if you're still working on that -- could you check if the same fix works for you as well? Thanks in advance!

PrimaryFeather commented 8 years ago

Lacking additional updates (and since I think this probably was more a Flash plugin bug), I'll close this issue now. Feel free to open it again if you want to continue this discussion.