Retina display on simulator & non-retina devices

[landoke]

Does anyone have any thoughts on how to develop in LiveCode for both retina display and non-retina display devices? If you develop at 320x480, this scales up 2x on a Retina display, which works fine, but looks low-res. If you instead develop at 640x960, it looks great on a retina display, but shows only the top quarter on a non-retina display device.

In Xcode, if you develop at 640x960, everything scales down automatically for you on devices 320x480. I can't seem to make this happen in LiveCode. I develop in 640x960 and I can only see 1/4 of the image when I run it in the simulator. When I install onto my iPhone 4, it looks great.

I don't want to have to make 2 separate versions of my app just to downscale to lower resolution devices...does anyone have any advice about how I should do this differently? I'm currently developing at 640x960 using "iphoneUseDeviceResolution true". Thanks!

[landoke]

In the absence of a real solution, I've taken to trying to resize every control on preopencard. It's a hack, and there's more specifics to handle, but here's a first run-through which hits most of my scaling-down issues. Touching up gradients, graphic effects (I touch up drop shadow), text field margins, etc. should be added:

Code: Select all

on preOpenCard
   if the environment is not "mobile" then
      exit preOpenCard
   end if
   
   iphoneUseDeviceResolution "true"
   
   if iphoneDeviceScale() is 1 then
      scaleDown
   end if
end preOpenCard

on scaleDown
      repeat with x=1 to (the number of controls of this cd)
         
         if word 1 of the name of control x is "graphic" then
               set the linesize of control x to round(max(1,the linesize of control x))
         end if
         
         // set each point of the rect independently, to avoid moving controls within a group
         set the rect of control x to \
               round(item 1 of the rect of control x / 2), \
               item 2 to 4 of the rect of control x
         set the rect of control x to \
               item 1 of the rect of control x, \
               round(item 2 of the rect of control x / 2), \
               item 3 to 4 of the rect of control x
         set the rect of control x to \
               item 1 to 2 of the rect of control x, \
               round(item 3 of the rect of control x / 2), \
               item 4 of the rect of control x
         set the rect of control x to \
               item 1 to 3 of the rect of control x, \
               round(item 4 of the rect of control x / 2)

         // is it a graphic?
         if word 1 of the name of control x is "graphic" then
               set the roundRadius of control x to round(the roundRadius of control x / 2)
         end if
         
         // check for graphic effects
         if the dropShadow["distance"] of control x > 1 then
            set the dropShadow["distance"] of control x to round(the dropShadow["distance"] of control x / 2)
         end if

         // is it a field?
         if word 1 of the name of control x is "field" then
            put the textheight of control x into tHeight
            set the textsize of control x to (the textsize of control x / 2)-1
            set the textHeight of control x to round(tHeight/2)
         end if
      end repeat
   end if
end scaleDown

[andyh1234]

I tried the resizing approach, but as soon as my app got a little larger (10+ cards) I found the perfomance, especially on startup suffered as I was asking the less powerful iPhone to resize everything before the app could start.

Ive switched now to having a core stack which controls all the code, and a running interface which I can deploy to the desktop.

I then create sub stacks for each device, iPhone, Retina, iPad, Android etc and simply use the behaviors feature to map the controls to the controls on the core stack.

The core stack loads, determines the device and resolution and shows the correct sub stack, and that stack is stored in a global so when the global is set the core stack items know to update the elements on the substack as well.

It can initally be a little daunting, but once I got used to it it actually works quite well as you can then design every interface differently, the iPhone and Android apps can look different, the iPad can enjoy some extra features and I can even set up a 'free' version that limits features easily, but the shared code base does the work behind the scenes regardless, and I can also deploy the mini app to the Mac app store. The apps also zip along as the devices are doing as little as possible.

To create the different interfaces, I initially create an iPhone standard interface, then when im happy with that duplicate the original project file, open it and run the resizing script to double everything, then copy these into my original app in a separate substack. I can then just replace any images with higher res versions and make any adjustments to items that need it, its a lot faster than it sounds.

The downside is the app is a little larger, but not as much as I originally thought and Im happy to trade the app size for a much better performance.

Just another approach!

Andy

[landoke]

Great thoughts, Andy!

I haven't tried the app on a non-retina display (outside of the simulator), so it didn't even occur to me how much time might be involved in scaling elements down on launch, although that makes perfect sense. It still seems like it would be great for LiveCode to handle the retina/non-retina sort of distinction on its own like XCode (did I really say XCode does something more easily than LiveCode??), but for the time being I'll deal with this model, and svaing multiple stacks seems to be a good compromise.

[dburdan]

If you are planning on making a retina capable app, just wait. RunRev is going to include support for automatic scaling in the next release. (However long that may take). So don't waste too much time with manual scaling.

[landoke]

Unfortunately my app is slated to be sent to Apple this week, so I kind of have to waste time for now

Thanks for the heads-up though. Looking forward to it. Here's to hoping the next version supports my other 2 pet peeves: speed speed SPEED (scrolling speed is totally unusable today--I use web browser views just to get around this) and background stuff (e.g., location tracking, local notifications).

[theagilepad]

Does runrev now have support for scaling between retina and non-retina devices?