Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

iPhone 4 problem!
Started by Alwayk Jul 05 2010 08:48 PM

- - - - -
98 replies to this topic
[TOPIC CONTROLS]
« Page 4 of 4 2 3 4
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#76

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@IgnacioIturra

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.
uid: 7356 topic_id: 1361 reply_id: 13867


[TOPIC: post.html]
#77

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

So if I do away with base content ratio I'm back to having to build an app for each device????
uid: 9371 topic_id: 1361 reply_id: 13868


[TOPIC: post.html]
#78

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@amigoni

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!
uid: 7356 topic_id: 1361 reply_id: 13870


[TOPIC: post.html]
#79

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

@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.
uid: 10835 topic_id: 1361 reply_id: 13873


[TOPIC: post.html]
#80

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

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!
uid: 9371 topic_id: 1361 reply_id: 13884


[TOPIC: post.html]
#81

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

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?
uid: 10835 topic_id: 1361 reply_id: 13887


[TOPIC: post.html]
#82

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

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...
uid: 9371 topic_id: 1361 reply_id: 13888


[TOPIC: post.html]
#83

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

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
uid: 10835 topic_id: 1361 reply_id: 13891


[TOPIC: post.html]
#84

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

see here

http://developer.anscamobile.com/forum/2010/12/04/simulator-add-ability-specify-resolutionscreen-size
uid: 9371 topic_id: 1361 reply_id: 13892


[TOPIC: post.html]
#85

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@IgnacioIturra

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).
uid: 7356 topic_id: 1361 reply_id: 13893


[TOPIC: post.html]
#86

evank

[GLOBAL: userInfoPane.html]
evank
  • Contributor

  • 317 posts
  • Alumni

@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.
uid: 3007 topic_id: 1361 reply_id: 13912


[TOPIC: post.html]
#87

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@evank

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.
uid: 7356 topic_id: 1361 reply_id: 13915


[TOPIC: post.html]
#88

evank

[GLOBAL: userInfoPane.html]
evank
  • Contributor

  • 317 posts
  • Alumni

@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.)
uid: 3007 topic_id: 1361 reply_id: 13922


[TOPIC: post.html]
#89

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

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?
uid: 9371 topic_id: 1361 reply_id: 13965


[TOPIC: post.html]
#90

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

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
uid: 7356 topic_id: 1361 reply_id: 14583


[TOPIC: post.html]
#91

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@IgnacioIturra

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...
uid: 7356 topic_id: 1361 reply_id: 15799


[TOPIC: post.html]
#92

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

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!
uid: 10835 topic_id: 1361 reply_id: 15800


[TOPIC: post.html]
#93

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

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!
uid: 7356 topic_id: 1361 reply_id: 15801


[TOPIC: post.html]
#94

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

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.
uid: 10835 topic_id: 1361 reply_id: 15802


[TOPIC: post.html]
#95

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

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...
uid: 7356 topic_id: 1361 reply_id: 15803


[TOPIC: post.html]
#96

craig.stowers

[GLOBAL: userInfoPane.html]
craig.stowers
  • Observer

  • 29 posts
  • Corona SDK

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...
uid: 40116 topic_id: 1361 reply_id: 45153


[TOPIC: post.html]
#97

green.castle

[GLOBAL: userInfoPane.html]
green.castle
  • Enthusiast

  • 63 posts
  • Corona SDK

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 :)
uid: 70391 topic_id: 1361 reply_id: 89187


[TOPIC: post.html]
#98

walter

[GLOBAL: userInfoPane.html]
walter
  • Moderator

  • 726 posts
  • Alumni

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.
uid: 26 topic_id: 1361 reply_id: 89678


[TOPIC: post.html]
#99

mikizee

[GLOBAL: userInfoPane.html]
mikizee
  • Observer

  • 7 posts
  • Corona SDK

This new image sheet interface sounds very exciting! I can't wait! :)
uid: 107380 topic_id: 1361 reply_id: 89703



[topic_controls]
« Page 4 of 4 2 3 4
 
[/topic_controls]