Understanding scaling and resolution on different devices.

atilim

Is there any way to set the project Image Scales appropriately so it will choose the "correct" (to my mind) value?

Currently no. Once this was recommended by @OzApps like:

application:setLogicalScaleX(1.0) application:setLogicalScaleY(1.0)

I can implement this feature.

bowerandy

@moopf I think 1/4, 1/3 or 1/2 keeps thinks pixel perfect. (1/2 means downscaling the graphics by integer 2).
@bowerandy Because if I choose 1, then cropping occurs.
And I'm always open to suggestions about the behavior of PP.

@atilim, but why is cropping a problem? I think that is what I'd expect it to do. Maybe, I'm missing the point, but the way it currently works doesn't seem useful at all, whereas, if it cropped it would be useful in these situations providing one understood that it may crop.

I suppose I'm looking for something that never scales the graphics but just picks the ones that "fits best".

best regards

moopf

@bowerandy, integer scaling on pixel perfect is valid and retains each pixel. Anything other than integer scaling doesn't, such as the 1/4, 1/3 etc., that's why I don't believe that pixel perfect should scale in this way and should scale no lower than 1x

@atilim I recommended something similar back in Feb as well:

http://www.giderosmobile.com/forum/discussion/476/automatic-scaling-question#Item_21

bowerandy

@moopf, yes I agree. With PP the assets should only be *upscaled* by x2, x3, x4 if correct sized assets are not available. My real issue is how Gideros chooses the assets based on the @half, @1x, @2x scaling factors. I think it should choose the nearest fit rather than one that doesn't crop.

So if @atilim implements the setLogicalScale() functions would this be equivalent to what you're suggesting in that thread and give me what I'm looking for? I must admit to finding all of this scaling stuff very confusing, which is why I had to build those demo templates in the first place.

best regards

moopf

@bowerandy I think it would yes, you can set your own scalings then. For instance if you set your project to letterbox as default, your app will then be able to use getLogicalScaleX and getLogicalScaleY (which are already available) to work out what scale Gideros has selected by default. You would then be able to force the scaling using setLogicalScaleX/Y, so if you detect that by default Gideros is using 0.9, you could force it to use 1.0

As far as I understand it the cropping is a bit of a red herring when thinking about what assets are used (at least it should be). As long as Gideros is adhering to the image scales you set in the project, then whatever you set the scaling to, Gideros should pick the right one from those settings.

The thing about scaling is that Gideros (and other packages) make it easy to uniformly scale content to different screen sizes. Many developers I've seen use these packages then forget about it and don't worry about it any more. The problem is that whilst that basic is useful, if you're interested in optimising the display as much as possible on different devices, you have to go much further. And that's where it gets more complicated.

Currently we don't have the facilities to exert much control over this in Gideros. Being able to set the scale mode at runtime was a good first step, being able to set the logical scaling (as @atilim mentions in this thread) is another good step. Gideros not opening the default images to work out scaling for higher resolutions would be another (I have a thread here on this: http://www.giderosmobile.com/forum/discussion/1906/how-gideros-processes-higher-resolution-images#Item_6). And being able to either re-write or force which images are used would be the final one. Then you've got complete control over the scaling at runtime and, linked with downloading images more suitable for the device it's running on, would enable you to tailor your display to as many devices as possible to give much better results whilst making the initial download as lightweight as possible.

atilim

I find cropping can be annoying because it can crop some useful area and I still believe that PP shouldn't crop any. And if PP doesn't allow scaling lower than 1x, then it'll crop 3/4 of the screen area if you select 320 x 480 as the device resolution in @bowerandy's demo project.

It seems it's hard to find a scaling mode (or a set of scaling modes) that fits all needs. Currently Application:setScaleMode function helps to overcome this limitation a little bit (e.g. set PP on iOS and set LB on Android). And I think providing the functions setLogicalScale/setLogicalTranslate will solve this problem all together.

moopf

@atilim I think we're coming from the same place on this. But, I don't think setLogicalScale will solve the problem completely if a developer is really interested in catering to a wide range of devices with the best possible output, whilst not inflating the app massively. That requires the further additions I talk about above. I can understand if it's not of interest to you at the moment, however.

atilim

@moopf yes I agree all. And this thread is directly related to your post: http://www.giderosmobile.com/forum/discussion/1906/how-gideros-processes-higher-resolution-images And I'm still thinking about using the base image's dimensions or not.

gianmichele

I think this is a problem that has been in TV and broadcast from day one. Anyone ever had to deal with PAL, NTSC, Overscan, 4:3, 16:9 etc?
I can assure you placement is really hell. Anyway, the idea is to design for the biggest resolution (or better squarish aspect ratio) and keep a safe area in mind. That way cropping is not a problem.

Dreemchest implements this on a resolution basis rather than scale:

http://dreemchest.com/doc/en/basics/resolutions.html

What do you guys think?

thanhquan1512

Here is what I have used before (for both IOS and Android):

Logical dimensions 480x800
Automatic scaling: Letterbox.

Then create all the graphics for these dimensions and second twice as size that will be used as @2 images.

Use filtering for all textures and fonts.

Create backgrounds in 600x854 (and 1200x1708 for @2) resolutions to cover both Iphone5 and Ipad2 whitespaces and position them in the center of the screen (probably using anchorpoint 0.5 is easier)

Use absolute positioning (ignoring scaling) for such elements as controls (to place them in the corners, etc).

That's all there is to it

P.S.: you could also use other logical dimensions, something that you find more suitable and calculate maximal offsets for whitespaces yourself. Basically I'm not saying that 480x800 is the best dimension to use, it's just something I'm using.

Thank you very much

This problem made most of my android submission was denied (except Google Play because there is no verification process)

EDIT:

However, when I try to setup using this guide, I encounter a problem. Even if I used a bigger background, it still be scaled to the defined logical dimension.

Change scale mode to "stretch" worked. No extra space in different resolution anymore.

atilim

@thanhquan1512 if possible try to not to use "stretch". As you can guess, it doesn't preserve the aspect ratio.

If possible, try to stick with "letterbox" and position your background with negative coordinates. For example assume that your logical dimensions are 320x480. And assume that you put a border to your background of size 50px (makes your background picture 420x580). In this case, position your background to (-50, -50) so that it will be centered and fill the empty spaces.

ar2rsawseen

@thanhquan1512 thats strange, have you tried an example project provide? Does it act the same? Maybe something's changed?

alexzheng

@thanhquan1512 if possible try to not to use "stretch". As you can guess, it doesn't preserve the aspect ratio.

If possible, try to stick with "letterbox" and position your background with negative coordinates. For example assume that your logical dimensions are 320x480. And assume that you put a border to your background of size 50px (makes your background picture 420x580). In this case, position your background to (-50, -50) so that it will be centered and fill the empty spaces.

Is it easy to add setScaleMode for Sprite to overwrite the global setting?
I always use letterbox for the project and calculator the postion and scale of the background myself to fill the screen. It would be better if we can use
background:setScaleMode(Sprite.STRETCH)

bowerandy

@moopf, @atilim, @ar2rsawseen or anyone else who can help.

I'm afraid I'm now at the stage where I want to get my app working on the iPhone in addition to the iPad where I've been doing all my development. I've reviewed all we've discussed above but I still don't get it. Please help!

First off, I tried @ar2rsawseen 's suggestion of using letterbox scaling mode and, unless I'm missing something, it still isn't good enough. Yes, with filtering on, it is *much* better than without but I'm afraid the non-power of two scaling of assets just doesn't cut it for me. On a retina display one can still discern artifacts at the image edges, which really misses the point of using retina graphics.

Can anyone explain what combination of scaleMode, logicalDimensions and image scales should I use to support all the current iOS devices without any stretching of graphics. I'd like to provide three resolutions of asset: @half, normal, @2x and I'd like to support the following devices in the best mode they can support:

old iPhone 320x480 = @half (logical area=768x1152)
iPhone 4 = 640x960 = normal (logical area=768x1152)
iPhone 5 = 640x1136 = normal (logical area=768x1362)
iPad and IPad mini (non-retina) = 768x1024 = normal (logical area=768x1024)
iPad (retina) = 1536x2048 = @2x (logical area=768x1024)

Ideally, I'd like the base logical canvas to be 768x1024 and use appropriate offsets to access the out of bounds areas on the (iPhone) devices that don't fit.

If those logical areas don't make sense, that's fine but could someone (*please*) explain what the best way to do iOS development is without adversely scaling the graphic assets.

best regards

SinisterSoft

I use the scaled method - no borders and scaling is automatic - works for evrything and looks ok. Then I work out the physical edges in relation to the screen. Then I work out a clipping region for most sprites.

I use the physical edge to position panels, controls etc - this way the game looks ok on any size.

Then I hold most of my game 'virtual' sprites in a table that is then depth sorted each frame. I then go through the table and feed any of my virtual sprite data that is within the clipping border into a bank of drawn sprites an, if the bank is short then create real sprites adhoc - if there are too many then I make the remaining sprite invisible (in case they are needed next time).

I don't have enter frame events for the different sprites - spurious events, memory allocation/deallocation, etc are what seem to be a big bottle neck so I try to reduce these.

I've tested it and (although it seems complex) for my type of game this seems to be the fastest way of doing it - I can have hundreds of depth sorted sprites running at 60fps without slowdown.

Also, don't forget there are some android devices that are almost square in ratio!

bowerandy

Hi @SinisterSoft, thanks for the reply. The issue isn't to do with performance it is to do with the artifacts that occur to textures when I use letterbox scaling. Basically, the problem is that any sort of non-power of 2 scaling is noticeable on a retina display. I want to be able to load assets at their real pixel size and then position them based on scaled coordinates.

From the discussion above, you'll see that I thought pixel perfect was the way to go but from @atilim 's comments it appears that this makes Gideros pick the (IMO) wrong versions of the textures (i.e. always the smaller size rather than the nearest size). For a time @ar2rsawseen persuaded me that "letterbox" was the way to go and that the 0.8333 downscaling of textures would look okay because the Gideros scaler is so good. I've now tried this using iPad assets on a retina iPhone and I'm afraid the artifacts are still visible.

I'm not interested in Android at present (my game requires Game Center and has some AI code written in Objective C anyway). I can see that the plethora of different Android devices make the convenience of "letterbox" almost essential. So my question is, what is the recommended way of getting the best possible appearance when using Gideros with iOS? Has anyone else come across, and solved, this problem?

best regards

SinisterSoft

It should really go for the nearest scale, I'm surprised it doesnt .

atilim

@bowerandy but it goes with the nearest scale. For example open the "Automatic Image Resolution" project (which is letterbox) and add this line to main.lua:

print(application:getLogicalScaleX())

and run with different resolutions. Here are the results (resolution,LogicalScaleX, prefix)

320x480 1 base 768x1024 2.133333 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 640x960 2 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 1536x2048 4.266666 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 320x568 1 base 640x1136 2 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 480x800 1.5 <a href="https://forum.giderosmobile.com/profile/1" rel="nofollow">@1</a>.5x 240x320 0.666666 base 540x960 1.6875 <a href="https://forum.giderosmobile.com/profile/1" rel="nofollow">@1</a>.5x 480x854 1.5 <a href="https://forum.giderosmobile.com/profile/1" rel="nofollow">@1</a>.5x 240x400 0.75 base 360x640 1.125 base 800x1280 2.5 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 600x1024 1.875 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 600x800 1.666666 <a href="https://forum.giderosmobile.com/profile/1" rel="nofollow">@1</a>.5x 768x1366 2.4 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 720x1280 2.25 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a> 1080x1920 3.375 <a href="https://forum.giderosmobile.com/profile/2x" rel="nofollow">@2x</a>

atilim

Also I've looked at some universal (and compatible with iPhone 5) games to understand how they do the scaling. I'm attaching the screenshots of one of them. Here, he's using a scale mode very similar to pixel perfect and he extends top/bottom for iPhone 5 and top/bottom/left/right for iPad.

Although you lose some game play area, I think pixel perfect is the way for iOS only games.

bowerandy

NOTE: @atilim, this is a response to your message timed 9:22pm (my time). I haven't checked the screenshots yet.

---

@atilim, I've tried this and I see what you're saying but let's just concentrate on the 4 iOS resolutions for simplicity.
320x480
640x960
768x1024
1536x2048

Go into the Automatic Images Resolution project with the print logical scale line included and change the scale mode to PP and the logical dimensions to 640x960. Then enable retina for iPhone and iPad. Now run on an iPhone 4 and and IPad 3. I get the logical scales:

iPhone4 = 1
iPad = 2

This is exactly as I would expect and works as as you suggest above.

However, I really want the base dimensions to be that of the iPad because it is squarer. This was suggested by @gianmichele above and is the way I have so far coded my project. So now set the logical dimensions to 768x1024 and re-run the test. Now you'll get:

iPhone4 = 0.5
iPad = 2

This is the issue I am experiencing. So are you saying that I should design for the most oblong (least square) device first and then adapt the squarer device code to fit?

best regards

atilim

ah I understand now.

The iPhone 4 resolution (640x960) can be placed within iPhone 5 (640x1136) and iPad (768x1024). Therefore you should choose 640x960 (or 320x480) with PP and so that you can fill the remaning areas (top/bottom for iPhone 5 and top/bottom/left/right for iPad).

On the other hand, I'm always open to other suggestions/solutions.