Closed kojot1234 closed 8 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!
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
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
Actually I just noticed I had that line in Staling.as so I did not solve it. "mClippedViewPort = mViewPort;"
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.
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!
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.
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