I’m revisiting/updating an older project that uses zoomStretch scaling (yes, it is intentionally anamorphic), but that scaling method has apparently been quietly removed (and is no longer listed in the docs). Why? Can you please restore it, thanks.
Hi Dave,
It’s still around for your use. We quietly removed it from the docs because it wasn’t a useful scale mode for much of anything: not games, not eBooks, not any app with text, not utility apps… so basically, we choose not to promote it. There are simply too many screen aspect ratios that will warp/distort that scaling mode in undesirable ways.
If you strongly feel that this should be restored, please make a reasonably convincing case on why. 
Thanks,
Brent
yep, my bad, false alarm, working now. maybe I corrupted the simulator- it kept returning device coords, which seemed like it was ignoring the scale mode, then I noticed it missing from the docs, and got worried. a reboot cured it though. (should’ve tried it on device) as long as it works, i don’t care if it’s not doc’d
… it wasn’t a useful scale mode for much of anything: not games,[…] so basically, we choose not to promote it. …
If you strongly feel that this should be restored, please make a reasonably convincing case on why.
uhmm… My game that has over 170k downloads should be a good case as to its use.
If done properly, ZoomStretch absolutely owns. Just for goodness sakes don’t get rid of it if you don’t understand its usefullness for pixel games. ( display.setDefault (“magTextureFilter”, “nearest”) )
@Lava Level,
You make a convincing enough case. I’ll re-add it to the guide, but with a very cautionary note that it should only be used in unique cases (like yours).
Brent
Yes, caveats are totally fine! Infact now I want to do an explainer!!
Ugh. When my current game ships I need to do a blog about how to make zoomStretch work well. There are ways to make it far less noticeable (use a base pixel format x2. Stick to square/rectangle UI design, not circle/curvy huds, design the work with the ratio most comfortable with shipping (ie. phone scale, vs tablet).
And it’s also good to note that the simulator will exaggerate the effect of pixels stretching where it is super hard to notice on device if the pixel graphics have a nice even resolution.
Because honestly, if the game functions well, nice and crisp pixels and graphics lined up good… the user rarely notices or cares that on one device the squares appear to be in 1.2 versus 1. Because these devices have such high resolution it’s really hard to tell the difference of a 1.2 and 1.0 x2 squared pixel if design rules are followed well. I think I’ve had 1 complaint that caught my attention regarding that out of all of mine, and it sounded like a developer that bought my title and was mad as if I was ‘cheating!’ :lol:
if you have “antique” assets at 1.5 (3:2) aspect, where it’s really not feasible to extend them for 16:9 aspect (or there’s no point in just filling the extra space with “junk”), or crop them for 4:3 aspect. then zoomStretch is also a completely viable solution. The ~20% difference from truly square pixels between 4:3 :: 3:2 :: 16:9 is not enough to worry about. (users are more vocal about “junk filling” letterbox bars, moreso than app-content-still-fully-occupies-screen-but-with-non-square-pixels)
it’s also trivially easy to set up a config.lua where you have a fixed content width and calc a content height (or vice versa) that exactly matches device aspect ratio. in such a case (when content aspect matches device aspect) then all of the zoom methods are equivalent (letterbox has no bars, zoomEven has no bleed, zoomStretch has square content pixels). this then offers a good “cheat” solution for using zoomStretch during android’s immersive mode for an app that might otherwise not be truly capable of responding to a dynamic change of resolution. in this case, the difference from non-square is even less, maybe ~5% at worst for portrait orientation.
and… if in either of those situations you further have “low resolution” content dimensions (to achieve a pixel look, for example) to begin with, then as per @Lava Level then there’s practically no discernable effect. zoomStretch in the right circumstances is just “easy”, and there’s often too much fretting over perfectly square pixels. (if you DO need to display an image with perfectly square aspect, say a trademarked logo or such, even that isn’t hard to achieve with zoomStretch by just “inverting” the content distortion with an opposing image distortion - I recently did a small contract job to achieve exactly that)
normally i’d use letterbox, for any app that has a content area that can actually respond dynamically. but zoomStretch has its uses.
Hi Dave,
It’s still around for your use. We quietly removed it from the docs because it wasn’t a useful scale mode for much of anything: not games, not eBooks, not any app with text, not utility apps… so basically, we choose not to promote it. There are simply too many screen aspect ratios that will warp/distort that scaling mode in undesirable ways.
If you strongly feel that this should be restored, please make a reasonably convincing case on why.
Thanks,
Brent
yep, my bad, false alarm, working now. maybe I corrupted the simulator- it kept returning device coords, which seemed like it was ignoring the scale mode, then I noticed it missing from the docs, and got worried. a reboot cured it though. (should’ve tried it on device) as long as it works, i don’t care if it’s not doc’d
… it wasn’t a useful scale mode for much of anything: not games,[…] so basically, we choose not to promote it. …
If you strongly feel that this should be restored, please make a reasonably convincing case on why.
uhmm… My game that has over 170k downloads should be a good case as to its use.
If done properly, ZoomStretch absolutely owns. Just for goodness sakes don’t get rid of it if you don’t understand its usefullness for pixel games. ( display.setDefault (“magTextureFilter”, “nearest”) )
@Lava Level,
You make a convincing enough case. I’ll re-add it to the guide, but with a very cautionary note that it should only be used in unique cases (like yours).
Brent
Yes, caveats are totally fine! Infact now I want to do an explainer!!
Ugh. When my current game ships I need to do a blog about how to make zoomStretch work well. There are ways to make it far less noticeable (use a base pixel format x2. Stick to square/rectangle UI design, not circle/curvy huds, design the work with the ratio most comfortable with shipping (ie. phone scale, vs tablet).
And it’s also good to note that the simulator will exaggerate the effect of pixels stretching where it is super hard to notice on device if the pixel graphics have a nice even resolution.
Because honestly, if the game functions well, nice and crisp pixels and graphics lined up good… the user rarely notices or cares that on one device the squares appear to be in 1.2 versus 1. Because these devices have such high resolution it’s really hard to tell the difference of a 1.2 and 1.0 x2 squared pixel if design rules are followed well. I think I’ve had 1 complaint that caught my attention regarding that out of all of mine, and it sounded like a developer that bought my title and was mad as if I was ‘cheating!’ :lol:
if you have “antique” assets at 1.5 (3:2) aspect, where it’s really not feasible to extend them for 16:9 aspect (or there’s no point in just filling the extra space with “junk”), or crop them for 4:3 aspect. then zoomStretch is also a completely viable solution. The ~20% difference from truly square pixels between 4:3 :: 3:2 :: 16:9 is not enough to worry about. (users are more vocal about “junk filling” letterbox bars, moreso than app-content-still-fully-occupies-screen-but-with-non-square-pixels)
it’s also trivially easy to set up a config.lua where you have a fixed content width and calc a content height (or vice versa) that exactly matches device aspect ratio. in such a case (when content aspect matches device aspect) then all of the zoom methods are equivalent (letterbox has no bars, zoomEven has no bleed, zoomStretch has square content pixels). this then offers a good “cheat” solution for using zoomStretch during android’s immersive mode for an app that might otherwise not be truly capable of responding to a dynamic change of resolution. in this case, the difference from non-square is even less, maybe ~5% at worst for portrait orientation.
and… if in either of those situations you further have “low resolution” content dimensions (to achieve a pixel look, for example) to begin with, then as per @Lava Level then there’s practically no discernable effect. zoomStretch in the right circumstances is just “easy”, and there’s often too much fretting over perfectly square pixels. (if you DO need to display an image with perfectly square aspect, say a trademarked logo or such, even that isn’t hard to achieve with zoomStretch by just “inverting” the content distortion with an opposing image distortion - I recently did a small contract job to achieve exactly that)
normally i’d use letterbox, for any app that has a content area that can actually respond dynamically. but zoomStretch has its uses.