> A wild guess is that your scene sets the anchor, scale or something. > I think that when growing ScrollingManager the unspoken assumption was that > the Scene in which it lives is a stock scene with default values. > By example, all the code for coordinate changes assumes the scene scale is > 1.0
The GameViewLayer has a ScrollingManager layer as a child, which in turn contains a ScrollableLayer for the hex map and another for rendering units. I've implemented my own hex map after having some unrelated trouble with the built-in HexMapLayer. No custom anchors or scales are being used by any layers. > > Resizing the window in the MenuLayer produces the expected behavior, however: the menu is still visible in the newly-resized window. > > I read it as: resizing the menu layer, then replacing with the gameview : > the gameview show but the menu also is still showing ? > > ??? I meant that resizing the window while viewing the MenuLayer works fine. The menu remains visible after the resize. This is before anything is done with the GameViewLayer. > > *Old Code* > > > > cocos.director.director.init( width=800, height=600, do_not_scale=True, resizable=True ) > > > > scene = cocos.scene.Scene() > > scene.add( GameViewLayer() ) > > cocos.director.director.run( scene ) > > # resizing the window has no effect on the game view > > what is no effect ? Here I meant that everything works fine. Resizing the window simply adjusts how much of the GameViewLayer I can see. The sprites are still rendered normally. > suppose the resize it toward bigger window size. > there is more screen area to draw. So, the draw into the window is not the > same. > > For do_not_sale=True, I expect more world area be shown on screen, at the > same scale before the resize. > > for do_not_scale=False, the default, I expect the same world area to be > shown, only scaled bigger. That is correct, and is what I see, except for in the situation where the GameViewLayer is shown after going through the menu. > if you are using do_not_scale=True and don' t do something in the event on_cocos_resize, then I expect: > . the window has more area > . the menu elements don't change size That makes sense, and is exactly what I'm seeing in the menu. > do_not_scale means that you want to handle explicitly the resizes. For that, > you should have somewhere a on_cocos_resize method, and register it as > listener for the the *director* event on_cocos_resize I don't want to handle resizes at all. I simply want more of the layer to be visible without any scaling. > There is a bug here, and seems to be related to grid transitions. > I modified the b0 example by adding an InitialScene that will transition to > the map scene and could repeat the problem (black window if resize after > transition). > > I pastebinded the modified test athttp://pastebin.com/KJJ7wtxK > > Look at the commented out lines in go_other_scenes: seems that all the > problematic transitions used grid transitions. > > I will look at this. > In the meantime the only workaround I can think is to use one of the non > grid transitions. I switched to FadeTransition, and that fixed the problem! Thanks Claudio! Also, I should mention an important observation: After the EnvelopeTransition, the "do_not_scale" appears to have been disabled. The sprite texture pixels weren't perfectly lining up with the screen pixels anymore. Using a FadeTransition didn't have this problem. Scaled sprites after using EnvelopeTransition: http://img130.imageshack.us/img130/4148/scaledscreenshot.png Unscaled sprites after using FadeTransition: http://img155.imageshack.us/img155/2003/unscaledscreenshot.png -- You received this message because you are subscribed to the Google Groups "cocos2d discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/cocos-discuss?hl=en.
