In the simulator it seems to run fine regardless of what skin I pick. Were you screen shots from a device build or from the Corona simulator or the Xcode simulator?
Rob
Corona simulator. But I have the same issue when it is installed on my device…
Craig
I ran it through multiple iPhone skins 4, 5, 6, 6p and it behaved correctly in all of them.
I ran a few other skins. On the really high resolution skins, that would use your @4x images, it had the problem you described. It looks like the graphic.newOutline isn’t generating the shape correctly when using the @4x image sheet.
This API looks for alpha transparency to draw the outline. It’s possible because your balloons fit edge to edge that it’s not creating the outline correctly.
Rob
Hi Rob,
If you are running my original zip file can you try it at Borderless Android xxhdpi (1920x1200) or iPad Pro. Or change the config.lua so it is 320 x 480… When running the config.lua from your tutorial it doesn’t swap the images until a MUCH higher resolution…
If this doesn’t cause this issue then I will try the sample app on different machine.
Thanks for looking into this,
Craig
Again, I suspect it’s the lack of transparency around the balloons. graphics.newOutline is failing and that’s about the only thing I see wrong.
Rob
Hi Rob,
I tried the app on a PC running windows 10 (my other machine is a Mac), and the problem is still there, I have attached another screenshot from the PC. I can see that the tracing of the balloons is a bit crappy - this could be to do with the transparency. However they are also in the wrong location, a number of pixels to the left and up.
Just to be clear, the issue I am having is that the physics body is appearing in the wrong location, not the shape of the outline itself - I don’t believe this has anything to do with transparency of images.
To see if this is the issue, I changed the sprites to individual sprites (no longer spitesheets). I copy and pasted the sprites themselves to a new transparent document (in Fireworks) and the ran it using newImageRect. You can see that the problem still exists.
If you are not seeing the problem, but I am seeing it on two different machines, Mac and Windows (which is a clean install), should I submit a bug?
Thanks,
Craig
If the image outline isn’t generated correctly positioning could be off. Did you add transparency around the balloon? Can you provide the current zip file?
Hi,
Here is the latest file. Had to compress the pngs so I could upload here. I really should learn how to use github or something…
Cheers,
Craig
Okay, here is the culrpit:
–display.setDefault( “anchorX”, 0.0 ) – default to TopLeft anchor point for new objects
–display.setDefault( “anchorY”, 0.0 )
Comment those out. The physics object takes the body’s x, y as it’s center, but when you set the anchor points to top/left it shifts the position.
Rob
Thanks, that answers the why its doing it… That gives me the reason, but still a problem, or rather two questions;
-
Why does this only happen with 2x and 4x images? I think this lack of consistency could be a bug? Or is it just the way it is?
-
If it is the later, then in my app I am using anchorX = 0 and anchorY = 1, I am doing this because I am importing the data from Tiled, which uses a similar coordinate system (I think Tiled uses 0 and 0), using default of 0.5 and 0.5 causes object to be position incorrectly in coordinate space. Would the easiest fix be to take the data from newOutline and shift is up and to the right?
Thanks Rob,
Craig
Hi Craig,
If you want to use the coordinates from newOutline(), but shifted, then yes, I think you could just loop through and add or subtract (depending on your respective anchors) half the width and half the height to all coordinates in sequence. That should align the body properly with the new anchors.
Brent
Thanks Rob and Brent.
One last question I promise…
Why does this only happen with 2x and 4x images? Everything lines up perfectly with normal images, cheers.
Craig
Hey,
First, I think this is an issue with the physics body and anchors, the documentation for addBody states that;
If you change the anchorX or anchorY property of a display object before adding a physics body, the body will be positioned properly relative to the adjusted anchor. However, you should not change the anchor point after adding the body or the object and body will be misaligned.
This seems to be true for regular images, but with @2x or @4 the image obeys the anchors but the physics body doesn’t seem to.
I played around with when I changed the anchorX = 0 and anchorY = 0 lines.
I discovered that if I add the lines before I add the physics bodies then (as it should be);
@1x = perfect
@2x = off by 1/2 width and height of object
@4x = off by 1 1/2 width and height of object
If I add the lines after I create the physics bodies then
@1x = off by 1/2 width and height of object
@2x = off by width and height of object
@4x = off by 2x width and height of object
The differences here tell me the physics engine is trying to do something, it’s just not working correctly. It would be interesting to get someone elses take on this.
Anyway, I came up with the following solution, it is not elegant but it works. In case anyone else has a similar issue…
In my setting file I have the following;
local scale = display.imageSuffix if scale == "@4x" then common.scaleFactor = 4 elseif scale == "@2x" then common.scaleFactor = 2 else common.scaleFactor = 1 end
I then call the following after I define the physics outline, I pass over the outline and the physicsObject (I could just pass over the width).
public.moveOutLine = function (thisBody, physicsObject) local modifiedShape = {} for k=1, #thisBody - 1, 2 do local pairX = thisBody[k] local pairY = thisBody[k+1] -- aPiece.width modifiedShape[k] = pairX + (physicsObject.width /2) \* common.scaleFactor modifiedShape[k+1] = pairY - (physicsObject.height /2) \* common.scaleFactor end return modifiedShape end
I hope this helps someone.
Craig