Maybe this has been addressed before - if so I’d really appreciate being pointed in the right direction!
I’m trying to upgrade the StrikeSapphire game code base from Away3d 3.6 to 4.1.1 right now, which is a pretty large undertaking. The site has a custom windowing system in Flash, similar to ASWing, that lets players have more than one game window open at a time, move them and resize them. Window.content is a sprite which in this case is filled with a class that extends View3D.
What’s apparent from testing is that if a View3D in 4.x is a child of a Sprite, resizing the Sprite doesn’t scale the view (which is fine, it’s easy enough to adjust width/height on the view). However, scaling the holding Sprite does scale the mouse interaction areas. Even if the View is then resized, the holding areas are off by a proportionally greater amount. example:
...
view.width = 1000;
var s:Sprite = new Sprite();
s.addChild(view);
//clickable areas are lined up perfectly over objects in the view.
s.scaleX = s.scaleY = 1.3; //or by setting width/height
//visible 3D elements stay the same size, but...
//clickable areas are now off to the right and down by 30%.
trace (view.width); //1000. Correct. We did not expect it to scale.
trace (s.width); //1300. Which is odd since the view isn't any larger.
...
setting the width/height on the view after this does nothing to alleviate the problem; the mouse enabled areas also scale when the view is resized. So they stay 30% of the total view size off from where they’re supposed to be.
The same effect seems to happen if you hit Cmd+/Cmd- in Firefox to zoom the Flash player size. Again, it’s not a problem if the context3d doesn’t scale, but then the mouse hit areas shouldn’t be scaling either, right?
So is this a bug, or… am I missing something? It seems to make it impossible to use 4.x in a windowing-in-Flash environment or even in a browser other than as a single, full-screen game.
