Scaling for different screen sizes?

309 views
Skip to first unread message

Azid Zeyre

unread,
Mar 4, 2013, 12:09:10 AM3/4/13
to aw...@googlegroups.com
So I know nme alone has the whole stage.setScaleMode() or something like that, but I ran my awe6 android game on a few screen sizes and on a smaller screen it cut most of the screen off... I'm not sure if this is just an isolated problem, but to be sure, how should I handle differeny device sizes in Awe6? Any sort of scaling option?

Rob Fell

unread,
Mar 4, 2013, 4:26:54 PM3/4/13
to aw...@googlegroups.com
If using fullscreen, try the options via IFactory.fullScreenType / awe6.interfaces.EFullScreen.
 
Otherwise use the Stage scaleMode by overriding AFactor._launchKernel:
 
 override private function _launchKernel():Void
 {
  super._launchKernel();
  _context.stage.scaleMode = StageScaleMode.SHOW_ALL;
 }
 
However, the above options just crop or scale content.  They don't rearrange content - which is arguably the better design choice - i.e. using elastic layout and / or different asset sets based on screen densities etc.  To do those things you will likely need awe6 to "read" AFactory.width and AFactory.height from stage.stageWidth and stage.stageHeight and apply formatting logic appropriately.

Azid Zeyre

unread,
Aug 3, 2013, 10:43:44 AM8/3/13
to aw...@googlegroups.com
SUper late, but could you clarify the "options via IFactory.fullScreenType/awe6.interfaces.EFullScreen"?

I set up my game so the placement of things for the most part relies on _kernel.factory.width and height, so hopefully that should work fine... I just need to figure out how to scale things correctly.

Azid Zeyre

unread,
Aug 3, 2013, 10:44:40 AM8/3/13
to aw...@googlegroups.com
Also, is there any way to adjust the game to a resizing of a window? Or to modify the width/height of the awe6 game on the fly?

Rob Fell

unread,
Aug 3, 2013, 1:24:38 PM8/3/13
to aw...@googlegroups.com
 
Sure, this is all possible - the comments in the EFullScreen source code are probably a good start:
 
But really it comes down to customisation and overriding _launchKernel with your desired choice.  E.g. fullScreen might not be appropriate, or if it is it needs calling in this function ( _kernel.isFullScreen = true; ).
I think manually setting factory.width and factory.height in this function opens up lots of routes for initial fluid layout.
And to manage resizing on the fly is a combination of Event.RESIZE and some clever (custom) methods to handle the corresponding layout changes.  General searches for AS3 fluid resizing will yield results here (the stage event will bubble to each Entity's _context).  Also check with other OpenFL / NME users.
 
However most of this is project view layout specific - as a general advice I'd avoid resizing pixels, and only resize the gaps between things (i.e. margins and stage alignments).

Azid Zeyre

unread,
Aug 15, 2013, 7:52:45 PM8/15/13
to aw...@googlegroups.com
Okay, so... in my Factory.hx, in the _configurer() method inside the if statement I added 
fullScreenType = EFullScreen.SCALE_ASPECT_RATIO_PRESERVE;


And below that, is this


 override private function _launchKernel():Void
{
 _kernel.isFullScreen = true;
super._launchKernel();
 //_context.stage.scaleMode = StageScaleMode.SHOW_ALL;
  
}

if I put the _kernel.isFullScreen= true; line after super._launchKernel(), the apk at least runs, but not fullscreen. 
if I put it before, as above, the game doesn't even open; a black screen appears for a split-second and the game closes on its own, on Android, no warning or anything, just returns to home.

Is there something I'm missing in regards to setting up fullscreen this way?

Rob Fell

unread,
Aug 15, 2013, 8:13:52 PM8/15/13
to aw...@googlegroups.com
If you put it before, then crash because _kernel is undefined at that point.
 
As for different StageScaleMode's in OpenFL native look at awe6.core.drivers.openfl.native.kernel._driverSetIsFullScreen
You'll see there is no special implementation (in comparison to Flash) ... so perhaps try changing StageDisplayState.FULL_SCREEN_INTERACTIVE to StageDisplayState.FULL_SCREEN ?
 
Mihail might have some input on this?

Bartek Bobko

unread,
Feb 8, 2015, 12:42:15 PM2/8/15
to aw...@googlegroups.com
In core/drivers/AKernel.hx, at _init(), why not using:

isFullScreen = _context.stage.displayState != NORMAL;

(instead of current: isFullScreen = false;). This way setting fullscreen="true" in project's .xml config wouldn't be useless.
Is there a reason to setting it this way (using setter in _init)?

Rob Fell

unread,
Feb 8, 2015, 2:21:22 PM2/8/15
to aw...@googlegroups.com
AKernel must be driver independent.  So it can't know of stage.displatState or NORMAL as they are flash package specific.
It calls the setter so that _driverSetIsFullScreen can react to the setting (in the case of flash driver, it will modify the ContextMenu).

Defaulting to false is probably not ideal - I'd agree it should default to whatever is current.  Can you help suggest how to implement that within the driver?

madneon

unread,
Feb 9, 2015, 12:18:49 AM2/9/15
to aw...@googlegroups.com
I'm not sure if I fully understand awe6 or OpenFL. Isn't openfl.dispaly.Stage platform-independent? And isn't stage (or context.stage) accessible in any driver's Kernel?
Maybe whole _configurer(...) should get as many data as possible from stage (fullscreen, width, height, fps...) and from assets/_exclude/config.xml (id, version, author...).

Rob Fell

unread,
Feb 10, 2015, 3:31:40 PM2/10/15
to aw...@googlegroups.com
OpenFL is a platform independent implementation of the Flash package.
awe6 does not depend on either OpenFL or the Flash package.  It can use them, or it can use alternative drivers (e.g. CreateJS or customer written drivers).
awe6's Context will therefore change dependent on the context of the driver, so we can't bind to Context's members from within the abstract classes else we'd lose driver independence.

From a practical perspective it is possible to override _configurer to read properties from the stage (or xml) if preferred.  Configurer occurs in two stages (once before the xml is loaded, and again after) for flexibility.
However the isFullScreen setting will assume a default prior to that (which I agree is not ideal).

Is there a particular problem this default creates?  i.e. something we can test against if I submit a patch.

madneon

unread,
Feb 12, 2015, 4:41:17 AM2/12/15
to aw...@googlegroups.com
Not a problem for me, just learning and trying to improve - I got this habit... ;)
Reply all
Reply to author
Forward
0 new messages