Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
Condition to see what scaled Images/Sprites are being used when Auto-Scaled — Gideros Forum

Condition to see what scaled Images/Sprites are being used when Auto-Scaled

Daimyo21Daimyo21 Member
edited May 2014 in General questions
So I understand Auto-Scale fairly well and have tested it with different resolution images and have seen it work.

My Question regarding auto-scale:

I am using physics editor to map out vectors for image/sprite assets and when these images/sprites are auto-scaled I need to be able to do a check to see which ones are being used(the 1x or the 2x etc.).

So example (this is just logic, not actual code):

if (using 1x auto-scaled images) then
local scaleFactor = 1.0
local physics = (loadfile "PhysicsData_for_1x.lua")().physicsData(scaleFactor)
else if (using 2x auto-scaled images) then
local scaleFactor = 1.0
local physics = (loadfile "PhysicsData_for_2x.lua")().physicsData(scaleFactor)
end

Is there a simple condition check to see what scale is currently being used?

Thanks!

Comments

  • ar2rsawseenar2rsawseen Maintainer
    There was a calculation data posted on the forum, can't find where now, writing from phone.

    But, if you are using Box2d, then

    Physics are just numbers, simply a model. You don't need to scale physics to match object size, because relatively they all will be the same and nothing will change
  • Daimyo21Daimyo21 Member
    edited May 2014
    I'm not actually using physics, I am using the vector mapping or vector points (like you would find in Adobe Illustrator) to give exact precision clicking on sprites/images.

    So if I am using auto-scale and it selects say 2x at a higher resolution, the Physics Data that I created for 1.5x resolution will make the coordinates all off. So really I need to be able to detect which it is using, 0.5x 1.0x 1.5x, 2x, etc. and then based on what it is using I change the scaleFactor for the physicsData.lua file.

    I can post a screenshot example if that helps if I am not being clear enough.
  • NascodeNascode Guru
    edited May 2014
    Hi @Daimyo21

    If i am not mistaken, i used only one definition of physics data, which is only for 1x asset. Then when the image is replaced with 2x, physics data will adjust accordingly, because i think physics use virtual resolution. No need to create many physics data for each resolution

    Oh and i use letterbox auto-scale mode
    have fun with our games~
    http://www.nightspade.com
  • ar2rsawseenar2rsawseen Maintainer
    edited May 2014
    @Daimyo21 yes as @Nascode said, if you are using Logical dimensions in your physics data, then logical dimensions are not changing.

    But if you still need it then:

    Let's say my base resolution is 320x480 (iPhone) and it runs on a device with 480x854. Thats a scaling factor of 1.5 in x-direction and 1.779 in y-direction. Lets say I have x1.4 and x1.8 graphics sets.

    Currently the formula is calculating average scaling by
    scale = (scaleX + scaleY) / 2
    In the example, the scale = (1.5+1.779)/2 = 1.6395 and it's near to 1.8 therefore Gideros will choose 1.8x.

    So you should store a table in all your supported resolutions and find the closest one to current scale ratio between logical dimensions and device dimensions (which you can get from application:getDeviceWidth/Height)

    Only note that device dimensions are always returned as if your phone is in portrait
  • Daimyo21Daimyo21 Member
    edited May 2014
    @Nascode Thanks for feedback, I was worried that I'd have to do physics data for all asset resolutions, I will test that and confirm.

    UPDATE:
    I can confirm that Nascode is right, it does scale properly when it switches from 1x to 2x etc..

    @ar2rawseen Thanks for the breakdown as I figured that may be one solution but I just didnt understand how auto-scaled calculated it so this helps tremendously.

    Likes: Nascode

    +1 -1 (+1 / -0 )Share on Facebook
Sign In or Register to comment.