Are display.contentScaleX and display.contentScaleY there yet in the API? I really need this to determine which spritesheet to use in the game. In the case that they are not there yet, are there any other way to check? [import]uid: 5976 topic_id: 1361 reply_id: 12846[/import]
Still not working. That’s a pitty. I am sure there is an explanation and hopefully a really elegant and good solution to this. Carlos brain is working on it I can hear it! [import]uid: 8192 topic_id: 1361 reply_id: 13832[/import]
@evank @Tom @carlos @walter … @Ansca
Please pay some attention to developers that ask for a way to do the most usual thing: to build a game with spritesheets that can run both on iPhone3 and iPhone4 from the same code. You are delivering high-level functionality with the new releases (facebook, openfeint, mapkit… etc) but the platform still lacks the ability to do ordinary things like proper scaling.
The promised feature of indirect device detection is indeed included in the new release but, gosh, it offers nothing to us! Why? Because it doesn’t work at the exact situation where we need it…
For display.contentScaleX to work we must have declared a base content dimension set within config.lua (e.g. width = 320, height = 480). If this set is not provided, the API always return 1 as contentScaleX.
So, suppose we set a “320*480” set in config.lua and depending on the device we get either 1 (ip3) or 0.5 (ip4) from the display.contentScaleX API call. Now, we provide two versions of a spritesheet: “ss.png” and “ss-hd.png”. We then check contentScaleX and we load the appropriate spritesheet version.
if display.contentScaleX==0.5 then
sheetName = sheetName.."-hd"
end We expect to see a sprite having the same size (as a proportion of the whole screen) both on ip3 and ip4, because we cover the increase of resolution on ip4 with a bigger spritesheet.
However, the result is a normal-sized sprite on ip3 but a *double-sized* on ip4. This should be expected, since Corona first brings the HD sprite for the HD resolution (so it would keep the proportional sprite-size the same, according to our plan), but then it also looks at config.lua and scales everything up to double size from there.
This happens for a scale=“letterbox” (or whatever). If we set scale=“none” the contentScaleX thing simply doesn’t work (always returns 1) and we get a half sized sprite on ip4 (the low-res ip3 spritesheet in HD device makes the sprite appear half-sized). The same happens if we don’t provide a base content dimension set in config.lua.
Ideally, we need to leave the whole base-content and scaling things unused in config.lua, but retain access to the device resolution somehow. The display.contentScaleX indirect way of detecting the device, requires a content-base and scaling setup to return a value. So, we come to a dead-end as I had cautioned you in my previous post above (see point 1).
I wonder why you don’t just give us the screen resolution as a number. You have it, since you need it to calculate contentScaleX (which compares device resolution with config.lua base resolution). This way we could just bypass this Flashy “base content” resolution thing and programmatically load assets depending on the device.
I am really disappointed with this outcome, after discussing the problem here for over a month (actually 3 months, see promises back in post #38) !
Please, give a quick solution to this problem. We can’t wait another month for such a core functionality…
[import]uid: 7356 topic_id: 1361 reply_id: 13793[/import]
@Ansca
BUILDING GAMES WITH SPRITESHEETS FOR IPHONE3/IPHONE4/IPAD/ANDROID
*** CURRENTLY AVAILABLE SCENARIO ***
1)Set base-content dimensions in config.lua (320*480)
2)Set scale=“letterbox” in config.lua
3)All the app assets are Retina (double sized)
4)Scale every object to 0.5 on creation
ADVANTAGES
On ip3 you get “half-of-double”-sized sprites (normal size)
On ip4 you trigger autoscaling so you get “double-of-half”-sized sprites (normal size)
You only provide one version of spritesheets (HD), so you keep app filesize down
DISADVANTAGES
You consume 4x runtime memory on ip3 (and other low-end devices)
Loading times get significantly increased on ip3
Performance drops on ip3, as the device handles 4x asset load
SYNOPSIS: Nice solution for ip4 and other high-end devices but a disaster for ip3 and low-end androids (where exactly you would want a performance *push* instead of a performance drop!).
*** DESIRED SCENARIO ***
1)All the app assets are provided in two versions (normal and HD)
2)We don’t use content scaling and don’t set base dimensions in config.lua
3)We use relative positioning of objects in our code (e.g. x=0.3*display.contentWidth)
4)We check the device resolution (TODO) and load the best spritesheet version
5)For some devices (e.g. ipad) that we don’t provide a custom spritesheet version
we can programmaticaly scale objects to achieve precise sizing.
ADVANTAGES
You get proper positioning and object-sizes on ANY device
You have Retina (HD) resolution on ip4 and other high-end devices
You consume 1x runtime memory on ip3 (and other low-end devices)
Loading times stay short on ip3
Performance stay normal on ip3, as the device handles 1x asset load
Ansca has only to provide a “display.deviceResolution” API call, to make this scenario possible
DISADVANTAGES
You provide two versions of spritesheets (normal and HD), so you increase app filesize
You handle the work for relative positioning (and custom scaling for not standard devices)
SYNOPSIS: Universal and efficient solution for ALL devices, as you have device independed positioning and proper resolutioned graphics, without bringing unnecessary overloads to low-end devices. Required additional work can be easily automated by 1-2 simple functions.
[import]uid: 7356 topic_id: 1361 reply_id: 13833[/import]
You get proper positioning and object-sizes on ANY device
Including Android? I wish! Please Ansca let’s do this!!!
Mind you what do you mean by ‘not standard devices?’ [import]uid: 9371 topic_id: 1361 reply_id: 13834[/import]
For example, if you provide two spritesheet versions: something.png and something-hd.png, with the second one being designed for iPhone4 Retina assets (960*640), you would get a little bit smaller graphics on iPad, which has a 1024*768 resolution. So you could just have a function(asset) that when called, it checks the device resolution and appropriately scales the asset to retain optically fixed-size objects on any resolution. This is actually an optional step, depending of how “bizzare” are the devices you want to support and what custom versions of spritesheets you provide. [import]uid: 7356 topic_id: 1361 reply_id: 13837[/import]
I’m doing pretty much exactly your desired scenario with the help of the new APIs.
Have you looked at this?
http://developer.anscamobile.com/forum/2010/12/08/dynamic-retina-spritesheets-heres-how
It works pretty well for older iphones and iphone 4. I’m using regular sprites for older iphones and the 2x ones just for retina devices that can handle the 4x memory requirements.
The rest of the images I let Corona scale using letterbox and 480x320 in config.lua.
Doesn’t work for iPad, since there’s no universal builds yet. iPad is read as 3G iphone as far as screen size goes (which is the desired behavior in an iphone build).
Haven’t tried anything on Android, but I’m sure it can be made to work. the xScale should just be a proportion of the display.contentScaleX. Then you’d have to decide how many different sprite resolutions to provide and scale the rest accordingly. [import]uid: 10835 topic_id: 1361 reply_id: 13841[/import]
Still would like to see an official ansca project that shows the ‘magic recipe’ working on all devices and by that I mean correct placement of object on iOS and Android devices. [import]uid: 9371 topic_id: 1361 reply_id: 13842[/import]
@Magenda. Now I read your post in a little more detail. You’re missing a crucial step when using display.contentScaleX. You have to then scale the spritesheet to 0.5 when you’re using it on iphone4 since the screen is defined as 480x320 in config.lua. You might think that this defeats the purpose of having high res spritesheets, but let me assure it doesn’t. The difference is night and day and unmistakable even for the most casual observer.
I’m using sprites to animate my main character that uses like half the screen (256x256) so the difference really matters. And the memory usage jumping from around 8MB to 25 - 30MB was worth it (framerate wasn’t affected in any way). [import]uid: 10835 topic_id: 1361 reply_id: 13844[/import]
You have right about scaling down the sprites on ip4!
How silly of me not to think of that…
So, we currently have a working solution for iPhone3 + iPhone4 
However, I still consider the “desired” scenario superior (and much desired), as it has all the advantages you mention plus it works on *any* device.
With content scaling you are locked to devices with same aspect ratio as the base content’s one you set in config.lua. The “desired” scenario involves relative positioning, so you have your objects cover the whole screen on any device, regardless the resolution and aspect ratio.
PS: Please make me a favor, as I don’t have an iPhone4 at hand: Take a look at a retina asset displayed with your scenario and then compare it displayed without any config.lua file (no base dimensions and scale) and without device detection. The same asset will be at the same size (in both scenarios) on ip4 but in first scenario it will potentially get a detail loss due to upscaling + downscaling, whereas in the second scenario it will be displayed as is. Do you see any observable detail loss?
Thanks! [import]uid: 7356 topic_id: 1361 reply_id: 13860[/import]
Nice but let’s not forget Android devices and the ‘weird’ resolutions… [import]uid: 9371 topic_id: 1361 reply_id: 13861[/import]
Glad you found it useful. I don’t think you’re limited to devices with the same aspect ratio though. Since I only care about iOS devices I just did it the simplest way posible, but if you’re working on Android a possible solution might be using the value you get from display.contentScaleX to do the scaling.
So instead of xscale = ,5 you’d do xscale = display.contentScaleX. That should work for every device I think. Though I’d have to test it and since I’m not planning any Android development any time soon, well…
As for your request I’ll take a look at it tonight if I have the time. But I don’t expect any detail loss. The retina spritesheet looks just as sharp as the static images in my game (I have a static image with the character in the same dimension as the menu screen so I can compare pretty accurately). The spritesheets work just as well as the Corona dynamic scaling (now if there’s a loss of quality with that, I don’t know, but I hardly think so).
Edit: @dweezil I don’t think there’s any problem in scaling for “weird” devices. Now positioning the stuff on screen is another matter entirely, but I don’t know what you expect Ansca to do about that. I like the way the coordinate system works right now with scaling. i.e you use one coordinate system for all devices (as in 480x320), it makes it much easier to develop, instead of having to rely on contentHeight variants for every single calculation. Of course it would be your job to make sure the relevant portions of the game stay inbounds on every device if you want to keep the aspect ratio constant. Otherwise use “zoomstretch” and forget about it. [import]uid: 10835 topic_id: 1361 reply_id: 13863[/import]
Don’t think I can use zoomStretch as I have spheres in my game. This is really getting me down. [import]uid: 9371 topic_id: 1361 reply_id: 13865[/import]
Let me make sure I understand properly. Right now I have design my game in iphone 4 dimensions to use dynamic Contente scaling with sprite Sheets to work?
What I mean is that my distances and dimensions have to be in iphone 4 dimensions. [import]uid: 8192 topic_id: 1361 reply_id: 13866[/import]
You are right about the universal sizing. I was talking mainly for universal positioning though, which I think is not possible as long as you have a “base content” ratio.
Thanks for your comments on quality loss (or no loss). These are good news! I am looking forward to the comparison with the native displayed retina asset too, whenever you (or anyone else intrigued) find the time. [import]uid: 7356 topic_id: 1361 reply_id: 13867[/import]
So if I do away with base content ratio I’m back to having to build an app for each device??? [import]uid: 9371 topic_id: 1361 reply_id: 13868[/import]
According to IgnacioIturra’s scenario, you set positioning on a 320*480 axis and you provide a normal.png and normal-hd.png (draw in HD and autogenerate both spritesheet versions with TexturePacker).
According to my scenario… you just wait for Ansca to provide display.deviceResolution()
If you just want ip3/ip4 support, go with IgnacioIturra’s scenario! [import]uid: 7356 topic_id: 1361 reply_id: 13870[/import]
@dweezil I don’t quite understand the problem you’re having since I haven’t touched Android development.
However as far as moving the balls using a 320x480 coordinate system should work fine on any device. so if you set your ball x,y as 0,0 it’ll be at the top left of the screen. 320x480 and it’ll be exactly at the bottom right. 160 would be exactly the same as display.contentWidth/2 and so on. I don’t see the problem, so can you be more specific.
As for positioning backgrounds, you’d have to design them big enough and with enough “bleed” to work well with any device. Again I don’t know what Ansca can do to help you with this. If you have platforms at the bottom then you can use yAlign = “bottom” on your config.lua to alingn it and the bottom and let the top bleed.
If you post the trouble your having right now in more detail, maybe we’ll be able to think of something. [import]uid: 10835 topic_id: 1361 reply_id: 13873[/import]
The trouble is (I think) that Android devices don’t have a 320 * 480 screen size. Some have 240 * 320, some 480 * 800 etc. The Droid one in the simualtor has something like 480 * 854 if I recall correctly.
I might be a little naive here but I want my game to look correct on ALL iPhones/Ipads and Android devices. JUST SHOW ME HOW TO DO IT WITH A WORKING PROJECT PLEASE ANSCA!
I *****STILL**** wait for Ansca to answer me. What a joke! [import]uid: 9371 topic_id: 1361 reply_id: 13884[/import]
It doesn’t matter what the actual screen size is. That’s the whole point of dynamic content scaling! If you set the x and y of your ball to 320 and 480 it will be exactly at the bottom right corner on EVERY device, be it 640x960 like iphone4 or 480x854 or whatever else you’re hitting. The screen coordinates will get mapped accurately to the device that’s running the game automatically.
Have you tried on the devices in question? What’s the problem you’re having? [import]uid: 10835 topic_id: 1361 reply_id: 13887[/import]