Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

Why the fuss with config.lua and variable aspect ratios? (Alternative code inside)
Started by rakoonic2 Sep 12 2013 12:20 PM

* * * * - 1 votes
30 replies to this topic
[TOPIC CONTROLS]
Page 2 of 2 1 2
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#26

dgaedcke

[GLOBAL: userInfoPane.html]
dgaedcke
  • Contributor

  • 264 posts
  • Corona SDK

we should probably remind readers that the "actual...." values describe values that are proportionate with the content scaling implied by config.lua (ie resulting contentScaleX & Y), where the pixel-values use physical hardware and ignore any effect of the scaling model.....in other words, "actual" can be used with the same percent/ratio calcs as contentWidth but are more descriptive of the full (100%) screen in the 0,0 model described above.  I'm quite sleepy so I hope this makes sense...someone else may want to reword this and also explain the difference from:    viewableContentHeight



[TOPIC: post.html]
#27

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,895 posts
  • Enterprise

display.pixelWidth, display.pixelHeight gets the actual device resolution in pixels.

 

display.actualContentWidth, display.actualContentHeight gets the device's actual screen size in "content area points" based on the defined width and height in config.lua.

 

Lets say you have a content area defined as 320 x 480 (and held in portrait mode).

 

Device        .contentWidth   .contentHeight    .actualContentWidth   .actualContentHeight    .pixelWidth    .pixelHeight

iPhone3gs          320                  480                        320                                480                            320                480

iPhone4/4s         320                  480                        320                                480                            640                960

iPhone5/5s         320                  480                        320                                568                            640                1136

iPad 2                 320                  480                        360                                480                            768                1024

iPad 3/4/Air        320                  480                        360                                480                            1536               2048

Kindle Fire HD    320                  480                        320                                512                            1600               2560

 

Hopefully those examples will help you understand what values are returned and when.



[TOPIC: post.html]
#28

mark.dallamore

[GLOBAL: userInfoPane.html]
mark.dallamore
  • Enthusiast

  • 31 posts
  • Corona SDK

Hi guys, I am starting to get ready to implement all my graphics and I was wondering whether its still really necessary for 360x570 graphics? Seems to be required less and less, is it still worth it?

 

Also I assume you need to create higher resolutions for all your graphics (such as items, characters etc)? For example if I have graphics that are around 32x32 that work well at 360/50 resolution should I just double it (and again) when scaling up the resolutions? 

 

Thanks,

Mark



[TOPIC: post.html]
#29

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,895 posts
  • Enterprise

Brent and I think it's probably time that many people can skip the 300px class of image sizes.  We started recommending a content are of 800x1200 as it's device agnostic (i.e. it's not an actual screen size) to get you out of thinking in terms of pixels.  But there is a problem with our widgets where some things like the widget.newPickerWheel isn't scalable and is designed for a 320x class content area.   If you plan to make use of widgets, you need to stay with the 320x480 sized content area.   There may be other reasons too.

 

But to us the benefits are:  1.  There just are not that many small screen sizes still out there.  Yes, we want to support every possible device, but at some point, you have to not support the tiny screens any more.  2. It cuts down on the number of files in the app bundle and while it doesn't save that much on space, it helps with your sanity.

 

Only you can decide how many of these older screens you want to support.  If that's important,  I would stay with the smaller content area because those devices have less memory and CPU to handle resizing the graphics down.



[TOPIC: post.html]
#30

dgaedcke

[GLOBAL: userInfoPane.html]
dgaedcke
  • Contributor

  • 264 posts
  • Corona SDK

Does CL have no plans to make the widgets scale??  I'm too far into my app (at 640 x 960) to revert back to 320x480 now.

So if CL is not going to make that improvement, then I'll need to do it or hire someone to do it while I'm working on other things.

 

The only one I really need is PickerWheel (as a date-picker).  Does anyone have any guestimates on how much work that would be??  Alex??

 

Thanks

Dewey



[TOPIC: post.html]
#31

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 25,895 posts
  • Enterprise

Hi Dewey I would say its not something we are going to tackle any time soon.  I don't know if there is an entry for it on the Feedback site or not or if it is how many votes it has.  But given our priorities and what engineering is working on it, adapting pickerWheel to be resizable isn't very high on the priority list.   I took a quick glance through the open source code and it seems to me the limits are based on the graphics used to draw the various chrome parts for the pickerView. 

 

You might be able to decode what's going on there, provide your own graphic frames at whatever size you want them and make it work.  However that's not a widget I've attempted that with.




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