Multi res / easy viewport managment, for next release (?)

[gsynuh]

ideas:

• CE will need base dimensions for your game and will store them - or by default flash stage size I guess. (finally explicit base dimensions for the game)
• CE will create viewport automatically unless asked not to - using various viewport modes we'll have (letterbox, show all, full, manual). -according to : https://github.com/alamboley/Citrus-Engine/pull/141 Will consider stopping forcing starling stage size, implying some camera rework.
• all citrus states could have camera set up by default... (with _camera quick access) but not enabled (so no updates by default.)

[mcapraro]

Hey there Thomas, just playing with stage size and viewports in my test game and not really getting it. hat you are proposing sounds really good - basically let me define the games size (lets say 640x480) and citrus does the rest to make it work on every screen properly. I would also be able to say, let me mange the pixels, give me the full resolution.

right now i am having trouble really figuring out how to get the screen to act properly in testing, on device, and on desktop and see the game scale properly.

[gsynuh]

Hey @mcapraro ,

assuming you do not touch the default viewport nor the starling stage size by default

• so : setUpStarling(true);

have you tried this in your state :

var camera:StarlingCamera = view.camera.setUp(target,offset); //don't setup the cameraLens argument we only need those two minimum

camera.zoomFit(640,480,true); camera.reset();

• its supposed to make a 640x480 area of the game fit in any screen you start with.

until now this is how I was doing it, it would zoom in or out the sprite that contains the state with the factor returned by zoomFit which essentially is simply calculating the ratio to fit the area into the camera lens (which is screen dimensions) and setting this as a baseZoom for the camera (when using the third argument as true).

so after this lines, all camera.zoom() or camera.setZoom() will be relative to that factor : in theory then, all camera operations will appear the same relatively on each device screen, keeping in mind that camera.setZoom(1); will get back to fitting that base area you want into that screen....

also then to know the applied base scale read camera.baseZoom or the number camera.zoomFit() returns.

-- if your screen doesn't need a camera or has no target to follow, the target could be a Point() set as the middle of your game level (otherwise the camera will focus on 0,0 if no camera bounds are set.

---

I suppose we do need all that automated somewhere cause the explanation is long (though it makes sense for me, it's useless to some) - this still doesn't let us have a custom viewport without the camera possibly mess up everything

[mcapraro]

Thanks for the detailed response Thomas, so this makes sense and it is working, and i agree that this would be nice to have automated somewhere. One of the things we lose with this approach is the built in starling scaleFactor so we have to handle scaling textfields and such in the HUD for example, where i think we get that for free if starling is set to manage the scaleFactor.

this isnt that big a deal, but it would be nice to have a global scaleFactor in citrus that we can just query and call. Right now it feels level specific which i think is OK but menus, hud and other things may need to make use of it too

[mcapraro]

thanks again Thomas for the suggestions, i have been testing and it works well.

thinking more about this and working through stuff, i noticed that the AnimationSequence.fromMovieClip() hard codes the scale factor at 1. wondering if there was a way to make this more dynamic (and sort of coincides with my previous comment). Especially since you may have created vector objects in flash, and having them be rendered smoothly every time regardless of scale would be nice

[gsynuh]

I'm glad this works actually because to tell the truth, it only made sense that it would work to me but I didn't have proof yet as I never tested with a set of different resolution textures.

For the AnimationSequence, If the first child, or the first child's child (makes more sense as the first child should be the first animation container of type MovieClip) is of type Shape, we can scale the full movie clip up by the starling scaleFactor (maybe sum it up with the current MC's scaleX/Y because it might already be scaled) before sending it to the dynamic texture atlas generator, hoping it will take it into account.

Or maybe let the user decide by giving the first animation a property such as "useScaleFactor" because we'll never be sure of where the "main" shapes are anyway and if maybe even though the first child is a bitmap, he'd still want the entire thing to be scaled up (its useless if the animations are only bitmaps of course, but its probably bad to start recursively looping through children to check if its the case)

... or add that as an argument to the fromMovieClip method, and when transforming it in StarlingArt, do that type check there - leaving us with the opportunity to decide programatically when using fromMovieClip ourselves but its less likely that one would use it like that I guess.

You should have a better idea of this, what you'd prefer to have as a workflow since you're using it right now and I don't !

[alamboley]

Hey guys,

I think we need to set up a (physics because many people wonder how to manage them with the multi-resolutions) demo with a camera and assets management. Until we don't have that, we won't be able to share the same example and see the issue that some other people may have!

So my question is: do you know where we can grab graphics which would be ok for iPad retina (or even Nexus 10) resolution, let say for a platformer game? This way we can work on the same prototype (just one basic level, the goal is to go through this level) and improve the camera or see what is needed etc. Obviously we will create sub SpriteSheets for lowest devices etc. What do you think?

[alamboley]

This demo will also include a basic GUI.

[mcapraro]

That would be great Aymeric. This art pack is used a lot for that and what's nice is that it has SWF and vector files so we could see examples of using Flash or just using standard spritesheets http://opengameart.org/content/platformer-art-deluxe

[alamboley]

Wow thanks for the link. There are the SVGs files that's great, however unfortunately there isn't the svg for hero animations... Do you know if I can find somewhere the hero in an highest resolution (for ipad retina, nexus 10)?

[mcapraro]

Good point Aymeric, i can probably throw a swf together with the hero animation in it, all the parts are there i guess he just didnt include it

[alamboley]

Well are you able to generate the character in a highest def? I don't have lots of skills on Illustrator ;)

Also we have to find an easy way to scale the svg spritesheets and generate the assets into png file. It would take time to save them one by one.

[mcapraro]

yes, I guess it all depends on how many tiles and frames in the animations :) it shouldnt be too hard though (i spend all day in photoshop and illustrator ;) ). let me know how big you think they need to be, what sprites we need, and i can go from there

[alamboley]

Awesome! Here http://pzuh.blogspot.fr/2013/05/citrus-engine-creating-level-using.html the game uses 600x400 resolution (I think this is the default assets size, we won't need more assets). The goal is to be able to design a game for the Nexus 10: 2560 × 1 600 px. So we would need them 4x bigger.

[alamboley]

In a second part, I will use Tiled to make the level for multi-platform resolution. But right now, let's focus on this starling viewport / camera system!

[mcapraro]

OK, do you still need these output at higher resolution?

Thinking more about this viewport/camera system and reading some of the requests and posts on the forums and git, i think it would be great to have this viewport issue sorted out and also a basic structure for menu screens, loading screens, pause screens, etc. i am trying to put together a template for myself to use and seeing where the holes are. For example, it would be nice to have a simple MenuState where we could just quickly throw the standard buttons on the screen and know it will work. Same for a Loading State or Loading Screen, where it just knows to find the main AssetLoader instance and shows the progress. This may not be what Citrus is about though, so i'm just suggesting them lightly ;) But my goal is to be able to jump in and very quickly (in the philosophy of citrus engine) have menu, loaders, pause screens, and game state prototyped.

I'm also planning Ad states and In App store states since that is such a huge expectation now in mobile.

[alamboley]

Yes, I need them 4x bigger than what they are right now.

The idea is to make a working demo for mobile/web/desktop. With let say a home screen, level screen, and ui in game, the demo will be completed ;)

[alamboley]

@mcapraro do you success to have them in a higher resolution?

[mcapraro]

hey there aymeric, sorry for the delay, client project took all my time. let me know if these work: https://www.dropbox.com/sh/q6yge43dr3mlo8g/I0iDAaDKwd

i didnt see the email for your last comment, sorry to keep you waiting. i scaled up the vector images and exported sprite sheets from flash. the hero is an animated walk cycle and the others are just static tiles

[alamboley]

Hey Michelangelo, no problem!

Wow, this is great! However I will still bother you a little bit ;)

• In a general term, may I had the pngs as a single file? This way I will be able to generate the Sprite Sheets in different resolution. Here if I can't generate a smaller SpriteSheet. No worries, I will do the boring stuff concerning naming files.
• It seems the hero graphics are missing the jump, idle, duck, hurt frames.

Otherwise, it's perfect. When I'm able to generate all the SpriteSheets, I will start the demo.

[mcapraro]

hey there aymeric, i have exported all the symbols as individual pngs. is this right?

[alamboley]

Thanks.

There are two things:

• the green guy as its "green guy walking0001" to "green guy walking0011" pngs animations has the default size, not the nexus 10 like the others one. Would you mind to generate them with the same size than the other one?
• the tiles pngs don't have the same size. Each png should be 280 x 280 aligned center, this way we will be able in Tiled map editor to set up one tile set. And the final SpriteSheets use for our game will use the trim option in TexturePacker so it will remove the empty space ;) It means one spritesheet for designing the level in Tiled Map Editor, and different SpriteSheets loaded at runtime depending mobile resolution to be used in the game.

Thanks again!

[mcapraro]

ok, sorry about the messiness there aymeric. you should find in the dropbox:

1. properly sized hero walking sprites
2. tiles that are all 280x280
3. hud elements separated from tiles

[alamboley]

Thank you sir! I've generated the SpriteSheets, I will work a bit on the level today. I will let you know when there will be something playable ;)

[mcapraro]

great, cant wait aymeric. when you have things working, you could also so a version where these are swf assets since i have them all as vector swfs too. then one set of swfs could be used to generate the right bitmap sizes on the fly.

[gsynuh]

Hey @alamboley , let me know when its done or where I can find that to try out the suggested automatic viewport setup system and update the way the starling stage is set up and everything. We have a forum post about nape's debug view not being in sync... it looks like the user is using a custom viewport - and so everything is messed up of course. I'd like to never see topics related to the camera on the forums ever (unless its a feature request) but I think that's completely my fault in the first place !) I just want it to work!!!

[alamboley]

Here we go: https://github.com/alamboley/Citrus-Engine-Examples/tree/master/src/multiresolutions

Very basic level right now... Feel free to design the level if you want, I will try to complete it in the next days.

The goal is to remove all this stageWidth for using the new var provided by the CE and make sure it works everywhere (air desktop, air mobile, web).

[mcapraro]

Cool, will check it out. So does this work with the starling scalefactor? I'm wondering how this works with some of the areas of code that are creating textures dynamically and could benefit from scale factor knowledge

[gsynuh]

Can I please write my point of view on all of this, and let me know if something sounds wrong or stupid. I'd rather have this clear in my head since I clearly don't have enough experience on multi res as you both have :

In this example, we should provide starling's asset manager with the right scale factor (we don't seem to be doing so) so that textures created from it will be using it. Also since we use the dynamic texture atlas generator in some places, it should also use that same scale factor - I have no idea if it tries to get it from Starling.current by default.

Anyway, in this example, an image of 2x, will be twice the size of 1x. the idea of using scale factor is so that whatever the scalefactor is, the size remains the same. If we don't provide the asset manager with that factor it will be kept at 1x - but the images will be bigger because the bitmap is bigger and so will be the texture...

That's why we would see no problem actually, because our starling stage is forced to fit the flash stage in CE, its scale relative to the flash stage is always 1.

What we want to be doing here, is leave starling do its own scaling, have all images be of the same size as 1x, but use the scale factor so that when scaling up those images (reporting the same dimensions) will be created from a bigger texture -> more pixel density (?)

[mcapraro]

I agree with this Thomas, mainly because in some cases you may want to provide a lower resolution experienced to gain more performance - as described in the starling wiki on multi resolution development. Also, being able to just develop with one set of screen coordinates in mind and the have starling do the rest is a big advantage too

[alamboley]

Hey guys,

Don't take into account (for the moment) the dynamic texture atlas generator, because in many cases we have so many spirtesheets that it is just a performance killer option. Also depending ratios, it may be hazardous to accept something we will never be able to try!

The default resolution of the demo is an iPhone 3GS (we design our game for that resolution), we want to have exactly the same game with an iPhone 4: meaning we don't want the camera to see more than in our previous resolution.

Compile and test the game with the iPhone 3GS resolution. Now let's try with the iPhone 4:

• the camera see exactly the same thing, however we have an issue at the moment because the position of each tile is not scaled by 2. So they overlap.
• if we set 2 to the new Starling.AssetManager(2); (so both have the same scale factor) we will see two times farest which is what we absolutely don't want. On an iPad retina we will see something like 4x more!!
• if we set 2 to the new Starling.AssetManager(2) but use assets at 1x, there are issues with positionning.

Based on this simple test, the easiest solution for me sounds to scale each graphics position by its scale factor and that's it. What do you think?

[mcapraro]

hi @alamboley, i havent tried it yet but will play with it tonight. it makes sense, but surprised about the positioning issue since i thought that is what starling is supposed to handle depending on the scale factor.

when i read this: http://wiki.starling-framework.org/manual/multi-resolution_development it sounds like the developer should always think they have the same size screen they develop for (320x200 for example) and that the scale factor will handle translating that for higher resolution screens and uprez the graphics if you have higher resolution images, so things stay crisp. it may not be how it works, but that was my impression.

the notion however, is very attractive because then i can concentrate on the game design and logic and not worry about special cases for every possible screen size.

[gsynuh]

My idea was to let the developer decide for a base resolution for his game - something he obviously did anyway - give those base dimensions to CE, and CE will setup everything according to the viewport mode we have selected (letterbox, fullscreen whatever). Knowing the base dimensions, the screen width and height, and the viewport mode we want to setup, we've got all the data needed - I think - for a good multi-res setup where we just have to write 3 lines of code (dimensions and viewport mode) - or even less. I

(since that means changing the camera and probably other things... I didn't try that out yet because I wanted to hear your point of view on how you manage multiple screens and resolution, and what would be the prefered way to do so. So I hope I understand everything right! )

[mcapraro]

hey there @gsynuh, this really sounds like a good direction to me. i think what has made citrus engine so amazing is that it can be really flexible but at the same time, i can get something quickly prototyped without having to think about too many things. it lets me focus on the game design (this is why i love the dynamic texture atlas from swf).

i think that modeling the game resolution setup in the way you describe helps support that. with minimal code, CE already does what most developers would want: you code to your starting game dimensions and CE will set everything else up automatically to handle that out of the box. again, i should be able to override it, but i can also not think anything of it, and CE will do what is most likely the best option.

if i could have one line of code that just says here are my dimensions, 1136x640 for example, and then on all other screens things just work. then if i want it letterbox form there, i can change that. if i want it to do different things on the ipad, then i can do that explicitly, but if i just supply the one line of code with my base screen size, it will all work like magic.

[alamboley]

Hey guys,

Maybe I miss something since a long time, but for me the manual isn't clear concerning the multiple-resolution.

For me, you have to design your gameplay (ui and levels) to a specific resolution, let say an iPad (1024 x 768). You will create different sizes of assets, 1, 1.5, 2, 4 ; you may have more, but you certainly don't want to have a lot (final package size).

Then you load the correct assets sizes. You have to multiply everything (positions) in your level by a ScaleFactor that YOU have defined. Also you can position everything with the elements side since it should be proportionnal to your ScaleFactor. Then you will have to manage the ratio, because on an iPhone 5 you see farest than on an iPhone 4 (platformer, landscape mode). Now you decide if you want to keep exactly the same content so letterbox for every > resolution and camera scale < for every < resolution until you have the same informations. You can base on the width, height or both.

I've never find myself something in Starling which could help me to do that. I know you can fix your Starling's stage to a static position, but I'm not sure it is a solution to a vast multi platform dev. That's why I did here: https://github.com/alamboley/Citrus-Engine-Examples/blob/master/src/mobilenapestarling/Main.as but it's easy because I know that I'm on an iPhone or an iPad. With all this android devices, how could I determine their lowest resolution?

Again, I may have miss somthing on Starling's side.

Yes, the user will have to fix a width / height for his game (the desired one) and then choose a mode (full screen, letter box), and the multi-resolutions should be managed. But don't forget to include (or not?) assets in the process.

[alamboley]

Ok, I've updated the demo with the position (and physics) scaled by the ScaleFactor: https://github.com/alamboley/Citrus-Engine-Examples/commit/138ca203d6e41601292f41c77728fac3f03690b7

I've copy/paste the existing one for adding ScaleFacotr. Note that we see artifacts at the moment, that's normal. I didn't extrude the textures, it is easiest this way to count the number of tiles ;)

So here, if you test with the iPhone 4 resolution, you will have exactly the same demo than using your iPhone 3GS.

However notice than everything in the physics is scale depending the scale factor (which isn't very cool). The mobilenapestarling demo had exactly the same demo because Starling's stage was excatly the same if you were on an iPhone 3GS or iPhone4, I think this is the trick...

If we fix a Starling's stage size, I think it should be everywhere the same! However how can we determine them for Android? And it means that our physics may change on each device resolution/ratio which is even worse than just scaling it !?

What do you think?

[alamboley]

Updated with the RectangleUtils.fit and the fixed Starling's stage.

I've also added images to 0,0 so we can make test without using the camera.

Now we have all the tools available, let's find the way to combine them...

[alamboley]

Ok, that would be the last message before waiting for your feedbacks ;)

I've added the Assets.ScaleFactor to the AssetManager and it works great. If we have a look on the level without the camera it sounds ok for all resolution. Now if I try with the camera (960 x 640), I can't see correctly my hero. I presume that @gsynuh doesn't grab starling stage size, correct ?

[gsynuh]

Hi, I played around with the multi resolution example. I'm launching it in a resizable window so I can see what's going on with the viewport - and I automatically reposition/resize it. It also reloads a state with new texture resolution if Utils.FindScaleFactor returns a different scale factor from the previous one... so we can try that in almost real time.

change the 'ViewportMode' in Main with a starling ScaleMode. NONE and SHOW_ALL work nicely I think... the problem with NO_BORDER is the viewport can be bigger than the window and so the camera can stop being centered on the hero. The camera needs to be sized like the viewport, I can consider another way of calculating it taking into account the fact that if the viewport is outside, the cameraLens should be corrected by a certain factor or things like that.

In the state's update, I correct the debug view by changing its transformMatrix - because the box2D debug view is no longer in sync with the starling coordinate system !

that's something I'll have to look at in StarlingCamera - or StarlingArt which is the class updating the position of the debug views.

I'll check if it works with rotation but I'm not sure it does really. edit: its fine. So I think it'll be ok for the debug views

[alamboley]

Hey,

Thanks for the experiment you've made. However it sounds for me than the Main is over complicated and I see some weird contents:

• why do we have a Assets.ScaleFactor and _scaleFactor? We should only keep one.
• the Context3DProfile.BASELINE_EXTENDED works only with iPad retina (and Nexus 10 I presume), so we should keep the switch.
• the super.handleStageResize method grabs _starling.stage.stageWidth = _screenWidth; ; so here it is the stage.stageWidth whereas in our demo we want a fixed stage!

On an other subject: a letter box is horrible. I don't want to have letterbox to my game. The way we should manage it I think, is : if we see larger than what we should -> scale the camera. What do you think?

[gsynuh]

Ok , the experiment is for experimental purposes, The _scaleFactor is so I can have a setter - that see if it changed or not and reloads the state with different textures (can cause errors though) - that happens mostly on resize. - I just tried to have something where you could resize the window to see what happens with the viewport and textures in real time - on a desktop, this is far from being final code !

Using BASELINE_EXTENDED by default here just so that the experiment doesn't complain when switching to 5x on desktop. I agree that the experiment in that case might need rework if you want to test it on an actual device , I just thought I'd first try out in desktop Air first.

in the demo,and in handleStageResize,I call resetViewport() which resizes the viewport, and do this as well _starling.stage.stageWidth = baseWidth; _starling.stage.stageHeight = baseHeight;

I didn't want to actually change the StarlingCitrusEngine class yet to implement functions that would be hidden from the user, so here I'm just adding on top of it for the experiment so I do call the super, but then use baseWidth/baseHeight as expected.

Have you played around with ViewportMode ? setting it to NO_BORDER should be the "fullscreen" we were talking about, SHOW_ALL would be the letterbox mode which I think I left by default... and of course NONE would be 100%. As you found out though, with NO_BORDER the camera does mess up because the viewport is actually bigger than the window, so the camera IS centered, but the window is too small to show us everything - that's where I also need to work. I could in fact scale the offset.x/offset.y to take into account the fact that the viewport is "cropped" by the window. maybe there's a better solution though -> still a bit confused by having an additional coordinate system here !

[gsynuh]

I understand you are worried about the complexity of the example, In fact I think I shouldn't have commited that there, but instead I should've created a new personal repository perhaps - sorry I was lazy.

in the end, for a user, the code should simply look like this

public function Main() { baseWidth = 100; baseHeight = 100; viewportMode = ViewportMode.FULL; }

of course there should be a MANUAL mode as well where one decides where the viewport is. The viewportMode would be used to correctly set up everything internally, almost like what's going on in resetViewport() - which could also be overriden anyway... This was a quick test sorry I couldn't do anything more yet. When I saw NO_BORDER being a problem for the camera, I didn't know what the best solution would be. If FULL would mean putting the viewport at exactly the same size as the flash stage, it would've also distorted the actual starling stage which is very bad cause the only solution to this is changing the baseWidth/Height to have the same ratio as the flash stage for less distortion and only scaling, which defeats the purpose of what we're trying to do here actually.

Also I may be missing something about having starling in fullscreen and what people usually do to have that, I mean is is really by using RectangleUtil.fit with the NO_BORDER mode or is there another way?

[gsynuh]

I've something to say about the "full screen" mode. Even if we've based our new thoughts around the fact that the starling stage should be fixed, I think that works only for 100% and letterbox. In fact, Strategy 3 in the multi resolution wiki page clearly says that we should consider resizing the starling stage , keeping the desired aspect ratio but simply having the viewport filling the flash stage - that actually means not using the NO_BORDER scale mode with RectangleUtils but simply setting the viewport to the width/height of the flash stage and setting the starling stage to keep the original ratio - in landscape, if we're going to have borders left and right in letterbox mode, then just stretch the starling stage left and right just as much (this is what I get from the wiki page)

No problems with the camera if its done this way. smart object placement should then be done not using the baseWidth/baseHeight but the new starling stage size.

reading back that article, and specially the Strategy 3, it makes complete sense. _ce.screenWidth/screenHeight might return the viewport size in that case, instead of the actual stage size (maybe should it be renamed) because we can't place starling objects outside of that viewport so there's no use in basing object positions (for smart placement such as sticking to the borders) with the actual flash stage size.

Does this mean we need a collection of values to support major screen sizes? can it really be automated... I still wonder the use of all of that appart from having letterbox and 100% readily available.

->The second sentence of this reply by Daniel is very explicit/related. http://forum.starling-framework.org/topic/multi-resolution-development-strategy-3-android-problem#post-9042

[mcapraro]

hey there @alamboley and @gsynuh , this is great stuff. i finally got a chance to play with the demo and its looking good. from playing around with it there are a couple of things that stick out for me:

1. it would be nice to have some easy way to access the starling stage width/height as that is what you will want to know a majority of the time to deal with your layout. i could see _ce.stageWidth and _ce.stageHeight being the most useful for me to position things like HUD elements, etc
2. i agree that letterbox is not an ideal case for anyone, but the logic makes sense: fit my game to any screen and make sure i dont lose any of it off the screen. now, in that case, is there a way i can have it behave that way, but still draw tot he edges of the screen? does that make sense? so if i have black bars on the top and bottom of the game screen, is there a way the stage can be expanded to fill those areas? it seems like in most cases that would be the most ideal as it would require the least amount of rework for the developer.
3. is there a way the scalefactor can also be part of _ce and used by other things like the objectmaker, etc? for support of using flash as a level designer/dynamic sprite creator. then if i have to create my own texture at some point, i can just use _ce.scaleFactor

[gsynuh]

Hello @mcapraro ,

1. thought of it, it would be a nice shortcut to Starling.current.stage.stageWidth/Height of course, and it wouldn't make sense anyway to use screenWidth/screenHeight to position things as the starling stage scale would now be different from the flash stage scale anyway.
2. see what you ask (letterbox but still fill up the border) means forcing the starling stage to a different size than the base size and put the viewport at the flash stage size - as explained in the wiki page - to avoid distortion so it makes sense. There is no way to expand, other than to force a different stage size. That pull request we recived that made me start this issue, was just saying that its wrong to for a starling stage size other than a base size. I went with it. Now that I've experimented it, I can say no its not wrong, its necessary - even on resize events (browser games, people using the browsers ability to zoom in/out, or maybe letting the game rotate on mobile rotate events)

We used to force it to be the same as the flash stage. Now of course the idea could be to force it to a stage size that would let us keep the "scale factor we require"... so expansion from the baseWidth/Height would be only in two directions, starting from a SHOW_ALL situation because show_all means we can only have two borders anyway.

In that wiki article, which is now my bible (other religious documents may apply) for this discussion, values for "extended stages" are hardcoded for devices, same as @alamboley kind of hardcodes the scale factors in his utils looking at the stage size - because the reported scale factor from starling is clearly never the same. (this util is based on the idea that we are in landscape mode however)

In any case if we expand the stage - which is the best way to have things - letterbox looks ugly, better to have a "responsive layout" ( :p ) than black borders, that means the baseWidth/baseHeight are clearly useless.

1. The scale factor Aymeric is getting, since its different fro the Starling.current.contentScaleFactor, I'm sure we'll have it as a public var to _ce for access when you are not using the asset manager, or using dynamic texture atlas, or creating textures yourself, that makes sense to unify everything as much as possible.

I would like to know why the Starling.current.contentScaleFactor is useless/not used in our example. when would our example fail by using it instead of the hardcoded scale factor?

[alamboley]

Hey guys, still playing with the example.. I noticed that if I set the resolution to 480 x 320 (the default one) and remove the camera, the tiles set up are no more aligned on top left but on middle of the screen. Can't see what is doing this trouble...

[mcapraro]

@gsynuh thanks for the explanation, and i agree that starting with letterbox and then resizing the width or height to fill in the rest is the smartest solution. it reminds me a bit of safe zones in video and print production where you purposely design slightly outside the area to be safe in case things get cut off - in our case its in case they get expanded ;)

for the scale factor question: yeah, i'm not sure if the starling scalefactor is different or not. i think its fine not to use it but only if that doesnt impact other functionality. for example, does feathers use starling.contentScaleFactor?

for the device sizes, i think this is a very tricky area. i'm sure we've all been on projects where we find no other recourse than to hard code different screen sizes and it never works for everyone anyway. especially on android, there is a seemingly endless number of screen sizes and new ones seem to come out all the time. right now my hope is that we dont have to think about other screen sizes and that this solution ends up taking care of things or even just satisfying the 90% of cases.

the other area that i think can be made more efficient is that actual generation of assets. it seems to me that if we are offering x1, x2, x3, and x4 assets, that we could just offer x4 and do some smart downscaling when we create the textures (why am am such a huge fan of the dynamic object creation from swf that is in Citrus).

[alamboley]

Offering x4 (4096 x 4096) won't work for many devices. Also sprite sheets of 2048x2048 won't be happy with iPhone 3GS etc.

Dynamic spritesheets creation isn't very good, if it is a big SWF it may take lot of time to be genrated on the device. What would be great is to generate things dynamically on the first app load, save them on the disk and then use it via Starling ;)

[mcapraro]

ok @alamboley , that is an awesome idea :+1:

[alamboley]

I've it in mind since several times. We need to fix this multi-resolution issue, and then I will work on that ;)

[mcapraro]

cool! would love to see that. hopefully i can finish up the game demo i have and move on to the next part which is using flash to layout UI for menu, level, and loading screens, then parsing the SWF to create feathers components and wire them up for actions.