Am I mad to ignore dynamic content scaling?

Well, if I don’t they come out twice the size :smiley: Everything I’ve read in the docs explains that they’re not part of the dynamic content scaling and that’s consistent with what I’m seeing. I’m using SpriteGrabber to access individual sprites in a sprite sheet as I come from a background of packing everything into a single texture - the basic functions in Corona seem to only be aimed at retrieving animations, not static imagery from a sprite sheet. I pack pretty much all images using TexturePacker as it’s more texture memory efficient and more efficient on draw cycles.

Or, dare I say it, am I missing something else :smiley: [import]uid: 115159 topic_id: 20717 reply_id: 81498[/import]

Aaah…silly me!
You’re talking about setting the xScale and yScale of your sprite right?
Yes that’s something you’ll need to do…sorry…it’s late here :wink:

I’m using Zwoptex myself to pack my sprites…

[import]uid: 70847 topic_id: 20717 reply_id: 81500[/import]

Yeah, that’s what I’m doing. I got Zwoptex a long time ago when I was working on an app in cocos2D but couldn’t get it to play nicely and ended up with TexturePacker which I’ve never had a problem with. [import]uid: 115159 topic_id: 20717 reply_id: 81501[/import]

I see.
The latest versions of Zwoptex work directly with Corona though.
It spits out a png and a lua file with the definition of each frame within your sprite sheet. [import]uid: 70847 topic_id: 20717 reply_id: 81503[/import]

Yes, so does TexturePacker which is why I’m still using it :smiley: [import]uid: 115159 topic_id: 20717 reply_id: 81504[/import]

Sounds good.

Anyway, glad to be of help with the scaling issue :slight_smile: [import]uid: 70847 topic_id: 20717 reply_id: 81505[/import]

Yeah, I really appreciate the help. Your posts today helped turn on the light bulb finally on dynamic content scaling. Cleared things up for me a treat! [import]uid: 115159 topic_id: 20717 reply_id: 81506[/import]

Hmm, just want to go back to the dynamic content scaling. I’m having an issue on the iPad with imagery not looking sharp. My config file is:

  
application =  
{  
 content =  
 {  
 width = 320,  
 height = 480,  
 scale = "letterbox", -- zoom to fill screen, possibly cropping edges  
 fps = 60,  
  
 imageSuffix =  
 {  
 ["@2x"] = 1.6,  
 },  
 },  
}  
  

That’s pretty much the same as ingemar suggested (I’ve tried with antialias=false and antialias=true and still get unsharp imagery.

Is there any way at all of forcing the dynamic content scaling to only go 2x on just the iPad, for example? Currently it’s coming out at something like 2.13333 [import]uid: 115159 topic_id: 20717 reply_id: 81685[/import]

Just found out that you can include logic in the config.lua file, so I’m now using this which retains sharp images on the iPad:

  
if ( system.getInfo("model") == "iPad" ) then  
application =  
{  
 content =  
 {  
 width = 320,  
 height = 512,  
 scale = "letterbox", -- zoom to fill screen, possibly cropping edges  
 fps = 60,  
  
 imageSuffix =  
 {  
 ["@2x"] = 1.6,  
 },  
 },  
}  
 else  
application =  
{  
 content =  
 {  
 width = 320,  
 height = 480,  
 scale = "letterbox", -- zoom to fill screen, possibly cropping edges  
 fps = 60,  
  
 imageSuffix =  
 {  
 ["@2x"] = 1.6,  
 },  
 },  
}  
end  
  

Basically on the iPad I’m just changing the height of the content to force it to scale 2x. This seems to work a treat to get pixel perfect scaling. This might also give some flexibility for other devices as well, to basically get Corona to tweak the scaling to suit. [import]uid: 115159 topic_id: 20717 reply_id: 81689[/import]

Hi again!

You say your images are not sharp on the iPad?
Since you’ve already looked at my app on Android, I’d be interested to hear what you think of my graphics on the iPad. You can download the free version from the AppStore on your iPad to compare.

I just use two versions of my graphics. Standard resolution and @2x resolution, and let Corona do the math for the scaling. [import]uid: 70847 topic_id: 20717 reply_id: 81691[/import]

Hi ingemar, I followed up that post with a solution that solves it by changing the content size for the iPad to force Corona to only scale x2, rather than 2.133333

Your Big Fat Goalie (just downloaded it) isn’t as sharp on the iPad - there’s just a slight softness on the images. That’s the nature of the particular scaling value Corona is using when you base the content size on an iPhone screen. Scaling down (hires graphics shown smaller than full size), such as on my Android tablet (which is 1024 x 600) is always better than scaling up in my experience - scaling up just seems to make things more obvious, to my eyes at least. And plus, on my Android tablet the screen density is higher than on the iPad (it’s a 7" tablet) and that helps as well.

But, being able to include logic in the config.lua file means you can tweak the scaling to suit different devices. That’s actually the perfect solution for me - gives me the granular control I need to make things look the best they can on multiple devices. [import]uid: 115159 topic_id: 20717 reply_id: 81694[/import]

OK. I just wanted your opinion just in case something else was going on :slight_smile:
I found that the slight fuzziness was acceptable when I was testing on my iPad.

Glad that you’ve found solutions that are working out for you! [import]uid: 70847 topic_id: 20717 reply_id: 81696[/import]

I don’t know if this is a bug or just a Fact of Life, but if your images are not powers of 2 (or at least evenly divisible by 2), they will appear slightly blurry even with NO SCALING applied. Powers of 2 textures are better memory wise too, so you should do it anyway. [import]uid: 120 topic_id: 20717 reply_id: 81907[/import]

Hi bryan, using texture dimensions divisible by 2 (e.g. 80 x 80 rather than 81 x 79) is a common requirement so it’s not a bug, and something I’ve always done anyway - it’s worth pointing it out though, as it can make people scratch their heads.

Powers of 2 textures are better as an 80 x 80 image would actually be loaded into texture memory in a 128 x 128 sized “hole”, wasting texture memory. That’s why packing multiple images into a single texture is so important, especially where you’re dealing with limited resources on mobile devices. [import]uid: 115159 topic_id: 20717 reply_id: 81918[/import]

Thought I might join the conversation here. Now I know the following probably isn’t the best way to go based on trying to create a smaller App size. But this config file has worked very well for me across ALL devices. I am currently released on iPad (all iOS Devices), Android, and Kindle Fire. It also works on Nook, but B&N is holding up my Account.

[code]application =
{
content =
{
–width = 793, -->> Dynamically creates the extra blank for the 20px Soft-Button for Kindle Fire.
width = 768, -->> For All other Devices as of 1.14.2011
height = 1024,
fps = 60,
scale = “zoomStretch” – zoom to screen dimensions (may add extra space at top or sides)

},
}[/code]
Take note I used “zoomStretch”.

I am not as advanced as you guys; but it actually uses my images scaled for iPad and automatically scales them down for the smaller screens without the “letterbox” effect. (I had originally developed my App “only” for the iPad).

Aside from larger files sizes for my images, is there any other negative issues with this thought?

[import]uid: 16527 topic_id: 20717 reply_id: 82254[/import]

@Rob Haney

The only drawback is if your images require a fixed aspect ratio.
Using zoomStretch will do exactly that. Zoom and stretch the content to fit, which will make round objects a bit squashed instead of round if the aspect ratio differs from the base content size given in config.lua.

letterbox maintains the aspect ratio regardless of actual screen size. However you need to have slightly oversized images to avoid the “black border syndrome” on different devices. [import]uid: 70847 topic_id: 20717 reply_id: 82255[/import]

Hi Rob, the only real drawback I can see to that is if the app is used on an older device (with a much smaller resolution screen, for instance) by using higher resolution textures you could well cause issues with the available texture memory, causing your app to crash. For instance, if your app is being loaded on a non-retina iPhone or iPod touch (which had less available texture memory) you could encounter problems. It really depends on how graphically intensive your app is though - if you’re not using many textures you may well get away with it. [import]uid: 115159 topic_id: 20717 reply_id: 82257[/import]

Thanks makes perfect sense. Thanks for the info. That will come in handy for the next app then.

[import]uid: 16527 topic_id: 20717 reply_id: 82258[/import]