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 3 of 4 1 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]
#51

Tom

[GLOBAL: userInfoPane.html]
Tom
  • Moderator

  • 1,480 posts
  • Corona Staff

I added the library support in future Corona DMGs as feature request #1448 (internal).

Thanks,
-Tom
uid: 7559 topic_id: 1361 reply_id: 7405


[TOPIC: post.html]
#52

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@evank

Regarding post 38, do you have any news on Dynamic SpriteSheet Resolution?

See here how TexturePacker is ready to accommodate such a feature, without breaking the coordinates.

Read here and the comments here about confusion on how to implement this functionality.

Personally, I was surprised to find out that when talking about "resolution independence", you only take into account simple images. On the other hand, you promote spritesheets as the preferred way to work with visual assets in Corona (as you should do) and you use this format as a major selling point for "Game Edition".

But, how should someone use SpriteSheets for a game if resolution independence is not provided? Is there any way to detect the device, the app is running on, to manually dictate the loading of the appropriate spritesheet png?
Really worried about what else I am missing...
uid: 7356 topic_id: 1361 reply_id: 10484


[TOPIC: post.html]
#53

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

I learned a lot reading this thread. I wish I could have found some of this information in the official docs.

Specifically, I didn't know that dynamic content scaling only works in one direction, up. If I want to develop for iphone 3 AND 4 it seems I MUST use the iPhone 3 resolution as the base coordinate system, rather than iPhone 4 (which is what I would prefer.)

And, as Magenda points out above, Spritesheets really need to work with Dynamic Resolution. These are two of the key benefits to developing games using Corona, but it they don't work together the benefits are muted.

I'm still unclear the best way to proceed. Simply, I'm trying to make a game that works on both iPhone 3 and iPhone 4, uses higher res. graphics on iPhone 4, and makes use of spritesheets on both platforms using a single code base. Is this possible now using Corona?

uid: 9422 topic_id: 1361 reply_id: 10514


[TOPIC: post.html]
#54

evank

[GLOBAL: userInfoPane.html]
evank
  • Contributor

  • 317 posts
  • Alumni

@XenonBL - actually, dynamic content scaling DOES work in both the up and down directions (I'll explain below why it doesn't seem that way).

To see an example of dynamic content scaling using a large content size and then DOWNscaling to smaller screens, check out the "SimplePool" sample project. Its config.lua file establishes the iPad as the base content size for the app:

application = 
{
	content = 
	{ 
		width = 768,
		height = 1024, 
		scale = "letterbox"
	}
}

...but then the game downscales nicely to iPhone3, iPhone4, Droid, Nexus One, etc.

However, here's the potential gotcha: there is a Corona "safety feature" that autoscales larger images by default -- this is discussed in the documentation for the display.newImage() API:

http://developer.anscamobile.com/content/display-objects#Image_Autoscaling

Specifically, the "safety feature" scales all images down to the next power-of-2 in each dimension, relative to the native screen size of the current hardware. So, for example, on iPhone3, all large images will be downscaled to no larger than 512 x 512.

Normally, this is harmless, and actually helpful, since it prevents users from accidentally blowing up all their graphics memory by loading a single large camera image. However, if you're trying to globally scale your entire project DOWN from iPad or iPhone4 to iPhone3, then you'll find that you're tripping the safety feature on iPhone3 by accident, since all large assets will be bigger than 512 x 512.

The fix is easy: just add the optional "true" parameter when loading large images, since this overrides the safety feature. In SimplePool, for example, you can see it in use here:

local tabletop = display.newImage( "table_bkg.png", true )
 -- "true" overrides Corona's downsizing of large images on smaller devices

In other words, you should be able to do what you want: size everything for iPhone4, and then globally scale the app down to iPhone3.

One caveat, though: remember that iPhone3 (pre-3GS) only has half as much texture memory as iPhone4 -- roughly 10MB vs 20MB -- so it is literally not possible to fully use the 20MB graphics memory of the iPhone4 AND still target the iPhone3. You'll need to keep that in mind, and watch your texture memory consumption to make sure the app still works on your lowest-common-denominator device targets.

To see how much texture memory is currently being used by your app, you can check the parameter named "textureMemoryUsed" in the system.getInfo() function, as documented here:

http://developer.anscamobile.com/content/system-os




uid: 3007 topic_id: 1361 reply_id: 10520


[TOPIC: post.html]
#55

evank

[GLOBAL: userInfoPane.html]
evank
  • Contributor

  • 317 posts
  • Alumni

@Magenda - you can get a LOT of information about the current device and platform using the system.getInfo() API:

https://developer.anscamobile.com/content/system-os

I agree that transparently uniting dynamic image resolution and sprite would be great, but there are a couple of background issues. First of all, there are very few possible dimensions for sprite sheets, and the maximum is either 1024 x 1024 or 2048 x 2048, depending on hardware and GPU. (The former case is more common, the latter case is iPhone4, iPad and not much else.)

It does seem like there would be a nice "2x" solution by automatically exporting a sprite sheet at 1024 and 2048 size from the sprite sheet authoring tools, but the other subtle factor is that a sprite-sheet construction tool will "pad" the separate images by an extra pixel or two, for certain technical reasons. This means that it cannot be guaranteed that the layout of the sheet will be the same for the 1024 and 2048 cases, at least some of the time.

In short, there is a way to do it, and it's a good idea, but it's a more complex implementation than images in general, and there will always be hard limits imposed by the limits of mobile hardware itself.
uid: 3007 topic_id: 1361 reply_id: 10523


[TOPIC: post.html]
#56

amigoni

[GLOBAL: userInfoPane.html]
amigoni
  • Contributor

  • 542 posts
  • Corona SDK

@evank Thanks for the explanation. What about the spritesheets. Is there a workaround to implement them?
@jonbeebe Thanks for the tutorial. Awesome as usual.
uid: 8192 topic_id: 1361 reply_id: 10524


[TOPIC: post.html]
#57

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@evank / @AnscaTeam

Honestly, I don't get it...

Firstly, system.getInfo() doesn't help since it doesn't provide the device resolution and the OS version is not mutual exclusive with specific resolutions (ios4 runs on both ip3 and ip4).

What scenario we need:

Step 1:
We save a spritesheet of 2048*2048 as "spritesheet.png" and then resize it with TexturePacker or whatever also to 1024*1024 as "spritesheet@ip3.png". The base dimension could be 1024*1024 and the second 512*512, or anything valid (TexturePacker automatically finds valid dimensions).
With TexturePacker we get these two spritesheets, each one with a different lua file. Everything is done automatically. No "pads", no bugs, no caveats... not messing around with coordinates or other things, not powers of 2 or 3. TexturePacker gives a valid dimension with the sprites registered absolutely right in the lua file for the new layout. Just don't bother with this side of technicalities.
We leave from this step with two valid spritesheet pngs and two valid lua coordinate-files...

Step 2:
Inside both of these two spritesheets, we have, among others, a sprite called "hero". From our code, we load "spritesheet.png" to extract the "hero" sprite. When Corona is about to read the "spritesheet.png" you want to get the resolution of the device (or what else helps you internally) and depending on whether the app is running on ip4 or ip3 to decide if "spritesheet.png" or "spritesheet@ip3.png" is going to be loaded. The accompanying "spritesheet.lua" or "spritesheet@ip3.lua" file will give the right coordinates.

Why this is not possible? Corona is involved only in step 2, and you already have done relevant work for simple images. I don't see any technical barriers here. If technical barriers existed, how Cocos2d has managed to do this?
uid: 7356 topic_id: 1361 reply_id: 10532


[TOPIC: post.html]
#58

Stephen Lewis

[GLOBAL: userInfoPane.html]
Stephen Lewis
  • Contributor

  • 716 posts
  • Enterprise

@evank, thanks for the information. I'm still trying to wrap my head around all this and perhaps I'm making it more complicated than it actually is. Are you saying that if I develop natively for iPhone 4, including using spritesheets, that my game will "just work" on iPhone 3 (as long as I don't go over the 10 mb texture memory limit of iPhone 3 and override the safety feature of Corona)? Or is there still an issue around spritesheets not translating correctly?

uid: 9422 topic_id: 1361 reply_id: 10536


[TOPIC: post.html]
#59

evank

[GLOBAL: userInfoPane.html]
evank
  • Contributor

  • 317 posts
  • Alumni

@XenonBL - The answer is "yes, it should just work". It's all OpenGL hardware scaling in the end, so you can freely scale the entire app up or down with no performance loss. This is why hardware acceleration is really nice!

The complexity only comes in if you want to selectively swap in different assets on iPhone3 and iPhone4, which is what Magenda is talking about (see my next response).
uid: 3007 topic_id: 1361 reply_id: 10548


[TOPIC: post.html]
#60

evank

[GLOBAL: userInfoPane.html]
evank
  • Contributor

  • 317 posts
  • Alumni

@Magenda - we're ultimately doing the same things as in that cocos2d discussion, but we're really trying to avoid using Apple's "points vs. pixels" vocabulary, for two reasons: it seems to confuse people, and it only works well in the special case where one device is exactly 2x the dimensions of the other device. Because Corona needs to handle many different iOS and Android screens, with different shapes and sizes, the "points" integer multiplier doesn't really help. Therefore, we came up with the notion of a base content size in config.lua (somewhat similar to "stage size" in Flash) and various ways to globally scale that content up or down.

To answer your question: yes, what you describe should work. You can detect the device, and then selectively load the assets you want. I was thinking more about future ways of handling everything transparently without making you build the assets twice.

How to detect the device? For starters, I just noticed that our system.getInfo() documentation seems to be wrong: I think we reversed the definitions of "name" and "model", so I just fixed that in our online docs.

The next problem is that Apple seems to like NOT allowing specific model detection. I just built a test project on my iPhone 4, and the value returned for system.getInfo( "model" ) is simply "iPhone". Evidently this is a standard problem, and the standard workaround is to test the points/pixels ratio in the OS and infer the Retina display from that (2=Retina, 1=not Retina).

Therefore, the fix that will ultimately help you isn't in the code you have, but it's in our codebase and will be released shortly. We are going to let you test the scaling factor between the base content size and the hardware screen size, which will not only return a "2" in the above Retina Display case, but will also return useful intermediate values on Android, iPad, and other screens that are not exact multiples. So you can use that as your iPhone 4 detector. The API looks like this:

scaleX = display.contentScaleX
scaleY = display.contentScaleY

(Note that these will generally return the same value, except in "zoomStretch" scaling modes.)
uid: 3007 topic_id: 1361 reply_id: 10549


[TOPIC: post.html]
#61

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@evank

Thanks for your answer, I am looking forward to the next release.

Some additional questions:

1) Supposing we have a way to detect the device (ip3/ip4/ipad), how is this "manual-spritesheet-loading" going to work cooperatively with the settings in config.lua? What would be the resolution there? Depending on the resolution, the whole objects-layout changes. Isn't this a dead-end ?
It seems to me that setting the content area from an "external" file, that you can't modify from within the app-code, may be good for dynamic scaling but not viable for programmatically loading assets depending on the device. Am I missing anything here?

2) If we manage to manually load spritesheets depending on the device, is everything else ready for building a "Universal" app, accepted as such in AppStore and working perfectly in ip3+ip4+ipad from the same build? Is there any other known issues to be solved for building "Universal" builds?

uid: 7356 topic_id: 1361 reply_id: 10812


[TOPIC: post.html]
#62

hima

[GLOBAL: userInfoPane.html]
hima
  • Observer

  • 22 posts
  • Guests

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?
uid: 5976 topic_id: 1361 reply_id: 12846


[TOPIC: post.html]
#63

amigoni

[GLOBAL: userInfoPane.html]
amigoni
  • Contributor

  • 542 posts
  • Corona SDK

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!
uid: 8192 topic_id: 1361 reply_id: 13832


[TOPIC: post.html]
#64

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@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...

uid: 7356 topic_id: 1361 reply_id: 13793


[TOPIC: post.html]
#65

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

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


[TOPIC: post.html]
#66

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

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


[TOPIC: post.html]
#67

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

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


[TOPIC: post.html]
#68

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

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


[TOPIC: post.html]
#69

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

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


[TOPIC: post.html]
#70

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

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


[TOPIC: post.html]
#71

Magenda

[GLOBAL: userInfoPane.html]
Magenda
  • Contributor

  • 427 posts
  • Corona SDK

@IgnacioIturra

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


[TOPIC: post.html]
#72

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

Nice but let's not forget Android devices and the 'weird' resolutions....
uid: 9371 topic_id: 1361 reply_id: 13861


[TOPIC: post.html]
#73

IgnacioIturra

[GLOBAL: userInfoPane.html]
IgnacioIturra
  • Contributor

  • 359 posts
  • Guests

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


[TOPIC: post.html]
#74

dweezil

[GLOBAL: userInfoPane.html]
dweezil
  • Contributor

  • 568 posts
  • Corona SDK

Don't think I can use zoomStretch as I have spheres in my game. This is really getting me down.
uid: 9371 topic_id: 1361 reply_id: 13865


[TOPIC: post.html]
#75

amigoni

[GLOBAL: userInfoPane.html]
amigoni
  • Contributor

  • 542 posts
  • Corona SDK

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.
uid: 8192 topic_id: 1361 reply_id: 13866



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