this is interesting but a bit outdated?
has anyone an update for this including the new high res devices like galaxy s3, galaxy nexus, ipad(3) etc. [import]uid: 12368 topic_id: 23200 reply_id: 116075[/import]
I am using this setup see a strange bug(?) in the simulator on landscape oriented projects; pick a device like the droid or kindle, then attempt to “tap” on an object to trigger an event. When the object is located in the “non-safe” zone on the right hand side the event won’t fire. Seems to work on the left non-safe side…
config.lua
application =
{
content =
{
--zoom
width = 320,
height = 480,
scale = "letterbox",
xAlign = "center",
yAlign = "center",
fps = 60,
imageSuffix = {
["@2x"] = 1.5,
}
},
} build.settings
[code]
settings = {
orientation = {
default = “landscapeRight”,
supported = { “landscapeRight”,“landscapeLeft”, “landscape”},
},
iphone =
{
plist =
{
CFBundleIconFile = “Icon.png”,
CFBundleIconFiles = {
“Icon.png”,
“Icon@2x.png”,
“Icon-72.png”,
},
},
}
}
[/code] [import]uid: 60707 topic_id: 23200 reply_id: 116399[/import]
@dkmac79 It isn’t outdated. The fundamental principle of this approach will never be outdated unless something changes in Corona in regards to content scaling. If you aren’t going to develop for lower resolution devices you can change the base resolution specified in config.lua if you want, as long as you understand how and why change it.
@chris.l.frederick You are correct and it appears to be a bug. AFAIK this has been present for a very long time. I still haven’t investigated fully if it’s possible to develop a workaround because I usually don’t need to catch touch events in the affected area. [import]uid: 61899 topic_id: 23200 reply_id: 116491[/import]
of course the principle is not “wrong” just wanted to know if someone has an update that includes newly introduced devices.
for example i have difficulty to get 1280res devices into the equation because the base size of the would then be 640*380 which is a lot bigger than 480*320 and there fore worries me a bit that the sd devices have to load a lot bigger textures than their screen size and the correlated memory usage… especially since those SD devices usually come with lower ram amounts than newer devices [import]uid: 12368 topic_id: 23200 reply_id: 116508[/import]
If you want to target mainly 16:9 devices with a display width of 1280 then you have to change the base resolution to an appropriate value, but I’m assuming by your questions that you still don’t fully understand what’s going on here. You don’t need to change anything to support newer higher resolution devices unless these devices are your main target for development in detriment of other devices. You always have to make a choice of what will be your central device resolution and aspect ratio, and that’s why the standard 3:2 aspect ratio of the iPhone was chosen. First it sits right in the middle of the other more common aspect ratios (4:3 and 16:9 or 10, or whereabouts) and second it is a very popular aspect ratio. You really have to forget about resolutions and start thinking in terms of aspect ratios. It appears that you are mixing content scaling and dynamic image resolution which is achieved by having different assets for different content scales (the @2 suffix stuff).
rxmarccall did a great job deconstructing all of this and creating a working example to start developing from. See his comments above. [import]uid: 61899 topic_id: 23200 reply_id: 116510[/import]
i fully understand the principle… and of course i am mixing scaling and dynamic image resolution because you surely won’t want to have an sd bg full blown (put perfectly scaled) onto the ipad3… because that would look horrible…
so its a mix between the principle of letterbox scaling in sync with offering the best texture sets for each “resolution” range
since you want to reach optimal image quality for as much devices as possible… from sd iphone, to retina iphone over to similar resoluted android devices over to high-res retina like 1280 devices over to the ipad3 with its extremely high resolution…
and its not as trivial as it sounds to get the optimal solution here, because scaling an item only based on resolution ignores the size of the screen and therefore the actual dpi used… which can easily lead to micro “button” or huge “buttons” or game elements or whatever you use…
especially considering all the rumors that the iphone 5 might be a 16:9 device (which would very well in most uikit based app) its not that easy…
of course this is also heavily dependent of the game… knifflig 
since you don’t want to scale your sd assets up to the full hd and beyond… you would want to have texture sets who take over at certain resolutions/ content scales to offer the best image quality [import]uid: 12368 topic_id: 23200 reply_id: 116514[/import]
@dkmac79
You will not see “micro” or “huge” buttons when trying to support device resolutions across the board. When you create an image with “display.newImageRect”, you set the width and height of the image to be displayed. No matter what size the true resolution is of the image file in your project directory, it will be forced to display at the width and height you specify with “display.newImageRect”. Have you read this blog post really well? http://www.coronalabs.com/blog/2010/11/20/content-scaling-made-easy/ [import]uid: 19620 topic_id: 23200 reply_id: 116524[/import]
of course the dpi of the screen plays a vital role how “big” an actual pixel is and therefore how big an image is shown… for example a button…
an tablet with a resolution of 1280*800 and a phone with the same resolution would load the same assets and use the same scaling factor which therefore would end up with either small or huge buttons , elements etc.
not?
[import]uid: 12368 topic_id: 23200 reply_id: 116545[/import]
Correct. This has been asked before and I think it’s a known feature request. So far the only way of knowing the actual screen size of a device is with a table of devices with the required information. I have a table with some of the more important ones, but of course it isn’t as accurate as having that information being read from the actual device. I have a lot more devices to add to that list but I haven’t had the time to do it.
Here are some resources related to the issue you mention:
http://developer.coronalabs.com/code/device-metrics-scaling-based-screen-size
http://developer.coronalabs.com/code/android-screen-sizes-and-names-list
https://github.com/cluelessideas/Android-devices-list [import]uid: 61899 topic_id: 23200 reply_id: 116602[/import]
@CluelessIdeas
Thanks for confirming I’m not crazy. It is a pretty frustrating bug. I’m hoping it does not occur on the actual device, but I’m not optimistic. I do use all the touch surface I can get in several of my apps…
@Ansca / Peach is there anything we can do to help get this issue fixed? Maybe some sample code that reproduces the issue? [import]uid: 60707 topic_id: 23200 reply_id: 116629[/import]
It happens on the actual device. Funny thing is that all other directions work fine. [import]uid: 61899 topic_id: 23200 reply_id: 116850[/import]
What a fantastic thread, thanks CluelessIdeas.
This subject has always confused me but it just clicked after reading your post.
Dave [import]uid: 117617 topic_id: 23200 reply_id: 118488[/import]
I don’t understand how this forum topic/method can be stickied considering that this implementation has a pretty major bug; parts of the screen don’t respond to touch events. Any update on this? [import]uid: 60707 topic_id: 23200 reply_id: 120423[/import]
Hi!
Excellent post!!
I was wondering what your thoughts are with regards to sprite resizing? Given that dynamic resizing won’t work for animated sprites, is there a recommended way of dealing with them? At the moment my background images look perfect on iPad retina but the sprites look crap?
Neil [import]uid: 173326 topic_id: 23200 reply_id: 122263[/import]
Hi!
Excellent post!!
I was wondering what your thoughts are with regards to sprite resizing? Given that dynamic resizing won’t work for animated sprites, is there a recommended way of dealing with them? At the moment my background images look perfect on iPad retina but the sprites look crap?
Neil [import]uid: 173326 topic_id: 23200 reply_id: 122264[/import]
Hi!
Excellent post!!
I was wondering what your thoughts are with regards to sprite resizing? Given that dynamic resizing won’t work for animated sprites, is there a recommended way of dealing with them? At the moment my background images look perfect on iPad retina but the sprites look crap?
Neil
P.S Sorry about the spam posting above! Accident and I can’t delete them 
[import]uid: 173326 topic_id: 23200 reply_id: 122265[/import]
Am testing my app on a Nexus 7 (works fine on iOS) and place my buttons using -
Main.lua -
local storyboard.globals.topY = display.screenOriginYIn my button code I use -
pencilButton.y = storyboard.globals.topY + 20On all iOS devices the button is fine but on the Nexus 7 the button is off the top of the screen.
EDIT: Ignore this, it all works fine. For some reason the Nexus was installing a old version.
Dave [import]uid: 117617 topic_id: 23200 reply_id: 123245[/import]
Awesome post! I really appreciate it
~ShiaDev [import]uid: 147340 topic_id: 23200 reply_id: 132303[/import]
Does this only apply to backgrounds? What about buttons? :S [import]uid: 184921 topic_id: 23200 reply_id: 137119[/import]
Hi rxmarccall
https://www.dropbox.com/s/mmlfxont1uo5oqj/UniversalBuildSkeleton.zip
I think the above link is no longer works can you re-post it some where?
Thanks [import]uid: 115578 topic_id: 23200 reply_id: 142491[/import]