More on Resolution Independence

[Nakia Brewer]

This sounds great! I bet the folks developing for Android will be especially happy....

Sent from my iPhone

> On 18 Nov 2013, at 9:42 pm, "Andrew Henshaw" <henshaw at me.com> wrote:
> 
> Ive been playing with this for the past few days now and it really is very smart.
> 
> If you simply leave all settings as standard,  and design for 320x480 and leave the engine to 'scale' the app up for retina displays what happens is all fonts, vectors and graphic effects seem to be automatically doubled in size (as opposed to scaled up),  while if images are referenced on the 320x480 display the standard image is displayed,  while on retina the @2x version is shown.
> 
> Two really easy ways to see the results are.
> 
> a)  put something different in the @2x images to show it is being used on a retina display or simulator.
> b)  compile the same app using LC6.5 and LC 6.1,  you can clearly see the difference in resolution and quality,  it is more than simply scaling as the fonts are all crisp,  vectors perfect and images are not just scaled up,  they are swapped for higher res versions.
> 
> It does look like a really good solution,  especially as it makes developing retina apps on a standard resolution display much easier!
> 
> Its just getting your head round the fact the screen is the same size so the design should be the same for both standard and non retina,  its just the images that need to be a higher quality for the higher quality displays and the engine takes care of everything else automatically.
> 
> Andy
> 
>> On 17 Nov 2013, at 21:15, Scott Rossi <scott at tactilemedia.com> wrote:
>> 
>> Still wondering if someone has an answer for this.  Anyone?
>> 
>> Thanks & Regards,
>> 
>> Scott Rossi
>> Creative Director
>> Tactile Media, UX/UI Design
>> 
>> 
>> 
>> 
>>> On 11/14/13 8:07 PM, "Scott Rossi" <scott at tactilemedia.com> wrote:
>>> 
>>> Some of the email posted tonight was a good excuse to dive deeper into
>>> new 
>>> resolution independence stuff, and I'm wondering if anyone can explain
>>> the 
>>> "recommended" development process here.
>>> 
>>> As a test, I have a stack that I create at 320x480 pixels on a desktop
>>> system.  With no special properties or functions applied, the stack
>>> *appears* to open at those same dimensions on an iPhone 4 (as reported by
>>> the rect of the card).  But in reading the 6.5 docs, I don't know if what
>>> I'm seeing is an auto-scaled view that is being *reported* as 320x480, or
>>> is actually a "natural density" 320x480.
>>> 
>>> I tried including an imported (non-referenced) image to see if I can
>>> determine any difference at the 320x480 size and I couldn't -- the image
>>> displays on the device at the same proportions as in LiveCode on the
>>> desktop.  Which makes me believe that there's no auto-scaling taking
>>> place, since I'm not using a referenced image.
>>> 
>>> When I add iPhoneUseDeviceResolution true upon opening the card, I then
>>> get the expected 640x960 view with controls proportionally smaller to
>>> match.
>>> 
>>> 
>>> If the scaling process is supposed to be "invisible", how can we verify
>>> that a stack and its contents are are being properly auto-scaled and
>>> taking advantage of the higher resolution?  Or am I missing a property
>>> setting somewhere?
>>> 
>>> Thanks in advance for clearing up my confusion.
>>> 
>>> Best Regards,
>>> 
>>> Scott Rossi
>>> Creative Director
>>> Tactile Media, UX/UI Design
>> 
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 

COPYRIGHT / DISCLAIMER: This message and/or including attached files may contain confidential proprietary or privileged information. If you are not the intended recipient, you are strictly prohibited from using, reproducing, disclosing or distributing the information contained in this email without authorisation from WesTrac. If you have received this message in error please contact WesTrac on +61 8 9377 9444. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. We reserve the right to monitor all e-mail communications.