I dont have the luxury of owning an iPhone 3, iPhone 4, iPad, all the Android devices to test on. I rely of the simulator, I stupidly presumed it should simulate the real device in terms of positioning etc (not performance).
I will knock up a demo… [import]uid: 9371 topic_id: 1361 reply_id: 13888[/import]
It does though. At least the ones supported. So if you’re having trouble maybe take a look at your config.lua? You might be doing something wrong there.
Also make sure you study this in depth:
http://developer.anscamobile.com/content/configuring-projects [import]uid: 10835 topic_id: 1361 reply_id: 13891[/import]
see here
http://developer.anscamobile.com/forum/2010/12/04/simulator-add-ability-specify-resolutionscreen-size [import]uid: 9371 topic_id: 1361 reply_id: 13892[/import]
I don’t think this is exactly the case, except if you have a “scale=zoomStretch”. How can a rectangle be mapped inside a (bigger) square? Blank stripes (unused space) are unavoidable with this mapping (“content scaling”) thing. Try to display a sprite at 0,0 and test it on the available Corona simulators (Simulator>window>view as). The sprite gets placed to 3-4 different positions. Imagine how this gets perplexed with the dozens of android devices available at the market today.
I think the only solution for absolute resolution independence is not to map at all (i.e. use relative positioning and dynamic asset loading instead of automatic content scaling). [import]uid: 7356 topic_id: 1361 reply_id: 13893[/import]
@Magenda - the easiest solution will always be to use content scaling, most likely “letterbox”, and then fill the extra space with nonessential content. I’m not sure “zoomStretch” is all that useful in the real world; it was more or less included just for logical completeness.
What I said in the other thread was to use display.contentHeight to get the bottom edge of the screen in scaled coordinates, and then use that as a reference for placing anything that needed to be at the bottom.
Alternatively, set yAlign = “bottom” in config.lua, which will ensure that the base content is always aligned with the bottom of the physical screen, although the top will then be variable. This might be fine if the top is just the sky, etc.
Another option, for a game with a platform at the bottom, would be to use the “zoomEven” scaling mode, which would keep both the top and bottom edges constant across iPhone and Android, but would crop the sides tighter on Android than on iPhone. That might be less work than having to manually reposition some game objects bases on the screen size, but it would mean having non-essential content at the sides.
In short, there is no way to keep all four corners aligned across different screen shapes AND not stretch the content. Since stretching the content is mostly unacceptable, you need to choose what is most important to align (and what can be potentially cropped), and this will depend on your specific design goals. [import]uid: 3007 topic_id: 1361 reply_id: 13912[/import]
Please read posts 62, 64, 67 and 70.
There is actually a way “to keep all four corners aligned across different screen shapes AND not stretch the content”! Relative positioning without content scaling.
Tell me something, please: Do you have the ability to read the device-resolution numbers internally? Regardless of whether you want to give it to us or not (for Apple reasons), if you can read it, I think I have thought of a very easy way to provide resolution independent Universal builds using: content scaling + relative positioning. [import]uid: 7356 topic_id: 1361 reply_id: 13915[/import]
@Magenda - right, but if you use relative positioning only, you end up with bigger gaps BETWEEN the content. So in that case you don’t stretch your content, but you do stretch your layout. (Which may be fine here.) [import]uid: 3007 topic_id: 1361 reply_id: 13922[/import]
So Ansca can we have a blog entry explaining this. I read the “magic recipe” blog but it doesn’t take into account correct placement for Android screens.
So I wonder is the answer to have perhaps a ‘cleverer’ buildsettings.lua.
So that you can specify the scaling etc depending on whether building for iOS or Android. Would that work?
At present the best option seems to be accept that all Android users will have to have black bars top and bottom. Perhaps the answer is to have two projects for the same game, one to target Android and the other for iOS.
Thoughts? [import]uid: 9371 topic_id: 1361 reply_id: 13965[/import]
I’ve managed to implement the “Desired Scenario”, firstly described in post 64, from within SpriteGrabber. It works nicely and seems to be 100% “Universal-ready” for games that use spritesheets to load graphics!
You can find some pre-release info here…
Thanks [import]uid: 7356 topic_id: 1361 reply_id: 14583[/import]
Have you also encounter the bug I describe here?
How do you scale down your sprites to implement HD-assets loading without been affected by that bug?
I encounter the bug with both your “scenario” and my “desired” one… [import]uid: 7356 topic_id: 1361 reply_id: 15799[/import]
No, because I’m using equally sized frames for my spritesheets. However I’ve noticed this while using the doubling the font size trick for getting retina text.
It’s not really a bug though.
Check out Bebee’s class. He supposedly has retina text working correctly, though I haven’t tried it yet. See if you can figure out how he did it. The same should apply to your spritesheets (it has to do with aligning stuff from either the center or the left, I’m not sure).
If you figure it out, do let me know! [import]uid: 10835 topic_id: 1361 reply_id: 15800[/import]
Text should be different from sprites, because it doesn’t have frames (so they can’t be unequally sized).
The other thing is that setReferencePoint doesn’t work with sprite (just another BUG) !
I’ll take a look at Beebe’s class to see if it has anything relevant though…
Thanks! [import]uid: 7356 topic_id: 1361 reply_id: 15801[/import]
Depends on the font you’re using. Not all are equally spaced. On the one I’m using I definitely see a massive shift if the score is say 111111 or 00000.
[import]uid: 10835 topic_id: 1361 reply_id: 15802[/import]
This is because the text is aligned.
I have managed to properly set up a “spritefont” solution that used spriteframes as letters and one separate sprite for each letter. There, I had the same problem and indeed I had to take into account the frame dimensions. However, in character sprites we don’t show a single frame but instead we play several frames as a clip, so there is no practical way to manually adjust the position of each involved frame depending on its dimensions variability.
There must be something wrong with the origins of the frames and the way the SDK takes them into account. Ansca has been informed about this and has registered the aforementioned other bug with setReferencePoint on sprites but nothing has changed since months ago that I firstly has discussed this issue…
[import]uid: 7356 topic_id: 1361 reply_id: 15803[/import]
thx for this thread guys, i have learned a lot from it. I was thinking, the scaling mode is fine if the screen RATIO’s are all the same. Filling extra gaps created by strange ratios with non-essential images is a good way to develop, but there is one other thing that would make this approach much more intuitive… Why cant the screen origin (0:0) be the center of the screen on any device? I guess this could be done by placing everything within a display group… [import]uid: 40116 topic_id: 1361 reply_id: 45153[/import]
bump.
Ansca, what is the word on dynamic content scaling for spritesheets? Coming some time this year?
I’m working on an app that is going to be roughly 90% sprites… Thanks in advance 
[import]uid: 70391 topic_id: 1361 reply_id: 89187[/import]
We’re currently creating a new set of sprite API’s that work with the new image sheet implementation that addresses some other performance issues (see http://developer.anscamobile.com/forum/2011/07/26/update-performance#comment-78027)
We plan to add dynamic content scaling support in image sheets so the new sprite API’s will get that for free. This will work in the same way dynamic content scaling works for normal images — each image is a scaled version of the 1x version, and your retina-quality version must fit within the max texture dimensions for the device.
We’re days away from seeding this to a couple of folks before we open it up to all subscribers. We’ll definitely make some noise when we do. [import]uid: 26 topic_id: 1361 reply_id: 89678[/import]
This new image sheet interface sounds very exciting! I can’t wait! [import]uid: 107380 topic_id: 1361 reply_id: 89703[/import]