Sprites, physics, scaling and groups

Audio and Graphics
#1

I am creating a game with a bunch of physics objects in a group that come from sprite sheets.  My goal is to have a scene that is 2 times as big as the device and have the ability to scroll around and have the camera follow the hero.  I have placed all my objects into a display group and then zoomed in by saying 

Gamegroup.xScale = 2 and Gamegroup.yScale = 2 

This seems to work and even the physics objects seem to scale correctly as I zoom in and out.  However, when I zoom in my images get blurry.  Before, I started switching to sprites I was using newimagerect and it allows you to state a size of the image.  So I was taking a bigger image and scaling it down when I created it with newimagerect.  When zooming the image stayed perfectly clear.  I guess because the image was really much bigger than the presented size.  How do people handle this normally?   I can’t be the first.  I tried scaling the image down after I created it but physics doesn’t seem to scale with me.  This is what I tried.  I put a test button on the screen and when I touched it the newfish changed scale.  

local function touch_test (event)

if event.phase == “ended” then

–  testsubject  do something to test subject

local newfish = testsubject

physics.removeBody(newfish.image)

newfish.image.xScale =  .5

newfish.image.yScale =  .5 

physics.addBody(newfish.image, “dynamic”, { friction=0.0, bounce=0.0, density=1 , filter = newfish.CF , outline=newfish.imageoutline} )

end 

return 

end 

From what i have read this should work but so far I have been unsuccessful.  If there is a better way please enlighten me.  I need enlightened. 

Just so you know this did fix the blurry issue.  It just created a physics problem.  

Thanks  Sweet

#2

Hi @laurasweet8888,

Generally speaking, you can’t move/scale groups containing physics objects (independent of other groups). You can scale/move the entire stage, but not scale/move one group while leaving other groups at 0,0. Another way to consider it: imagine that each group that contains physics objects is a “layer” in itself. While physics objects in every group will interact with each other, Corona assumes that each group is positioned at the same coordinate space AND in the same scale, because that is how it computes collisions between objects.

Hope this helps,

Brent

#3

Thanks, that explains why I can scale the whole gamegroup but not a displaygroup inside the gamegroup or in this case an individual object.  But somehow newimagerect does it, so I guess I thought it would be possible with sprites.  If I scale the object before it is turned into a physics object I would think that this would work.    Is there a work around that you know of for by blurry zoomed sprites that you know of?  

thanks,  Sweet

#4

Hi Laura,

Did you properly configure the sprite sheet to be compatible with dynamic image selection (higher-res sprite selection)? This entails adding the sheet’s overall width and height when setting it up, so Corona knows that it should pull from the proper higher-res sheet. It’s a similar concept to using “display.newImageRect()” but in this case, “display.newSprite()” will work in a similar fashion.

Best regards,

Brent

#5

Brent,

   Yes I was doing the proper content scaling.   My problem is that I defined my content area to match each type of device I would encounter.   For example an Iphone 4 would be 720 by 960.   I wanted my world to seem bigger than that so I was using xScale to simulate zooming in on the section of the world I wanted to be in camera view.  All worked fine with newimagerect because I could auto scale the images down from a bigger size and they would stay sharp without physics getting confused as I zoomed in.   I now realize that I just need to make my world content area much bigger.  Let’s say on an iphone 4 make the content area  1280 by 1920.  Then when I zoom in by 2 the content area would then match the device and everything would stay sharp.  

    I think this creates a problem with the config.lua auto selecting images because the now the relationship of display.pixelWidth ,  display.actualContentWidth is reversed.  If I read the doc correctly if I say ["@2x"] = 1.5 this means 1.5 and above.  Now as my device gets bigger the ratio would get smaller.  Is it possible to use something other than an = sign in this expression?  I need this to say “<=”.   At this point do people just give up on config.lua and write their own image loading functions?   

    This new method also creates a problem on big devices because I can not load an image 2 times as big as a S5.  The image would be huge.  So the background loading on large devices would have to be pieced together from multiple pictures.  So I guess a device picture loading function is mandatory anyway.  

    Thanks again for the advice.  I am just making stuff up and guessing what would be best.  It is always nice to bounce ideas off of someone who has written this type of thing before.  

#6

Hi @laurasweet8888,

Generally speaking, you can’t move/scale groups containing physics objects (independent of other groups). You can scale/move the entire stage, but not scale/move one group while leaving other groups at 0,0. Another way to consider it: imagine that each group that contains physics objects is a “layer” in itself. While physics objects in every group will interact with each other, Corona assumes that each group is positioned at the same coordinate space AND in the same scale, because that is how it computes collisions between objects.

Hope this helps,

Brent

#7

Thanks, that explains why I can scale the whole gamegroup but not a displaygroup inside the gamegroup or in this case an individual object.  But somehow newimagerect does it, so I guess I thought it would be possible with sprites.  If I scale the object before it is turned into a physics object I would think that this would work.    Is there a work around that you know of for by blurry zoomed sprites that you know of?  

thanks,  Sweet

#8

Hi Laura,

Did you properly configure the sprite sheet to be compatible with dynamic image selection (higher-res sprite selection)? This entails adding the sheet’s overall width and height when setting it up, so Corona knows that it should pull from the proper higher-res sheet. It’s a similar concept to using “display.newImageRect()” but in this case, “display.newSprite()” will work in a similar fashion.

Best regards,

Brent

#9

Brent,

   Yes I was doing the proper content scaling.   My problem is that I defined my content area to match each type of device I would encounter.   For example an Iphone 4 would be 720 by 960.   I wanted my world to seem bigger than that so I was using xScale to simulate zooming in on the section of the world I wanted to be in camera view.  All worked fine with newimagerect because I could auto scale the images down from a bigger size and they would stay sharp without physics getting confused as I zoomed in.   I now realize that I just need to make my world content area much bigger.  Let’s say on an iphone 4 make the content area  1280 by 1920.  Then when I zoom in by 2 the content area would then match the device and everything would stay sharp.  

    I think this creates a problem with the config.lua auto selecting images because the now the relationship of display.pixelWidth ,  display.actualContentWidth is reversed.  If I read the doc correctly if I say ["@2x"] = 1.5 this means 1.5 and above.  Now as my device gets bigger the ratio would get smaller.  Is it possible to use something other than an = sign in this expression?  I need this to say “<=”.   At this point do people just give up on config.lua and write their own image loading functions?   

    This new method also creates a problem on big devices because I can not load an image 2 times as big as a S5.  The image would be huge.  So the background loading on large devices would have to be pieced together from multiple pictures.  So I guess a device picture loading function is mandatory anyway.  

    Thanks again for the advice.  I am just making stuff up and guessing what would be best.  It is always nice to bounce ideas off of someone who has written this type of thing before.