This could potentially break any code relying on group.width and group.height:
[lua]local test = display.newGroup(display.newImage(“myImage.png”)) – myImage: width: 256, height: 256
test.xScale = 0.5 – new dimensions for group should be 128, 128
print(“Width:”,test.width,“Height:”,test.height) – prints 256, 256
– note: same result if using test:scale(0.5,0.5)[/lua]
Is it possible to have a hot-fix before next drop ? [import]uid: 5750 topic_id: 4391 reply_id: 304391[/import]
Could not edit post, just forgot to scale Y:
[lua]local test = display.newGroup(display.newImage(“myImage.png”)) – myImage: width: 256, height: 256
test.xScale = 0.5 – new dimensions for group should be 128, 128
test.yScale = 0.5
print(“Width:”,test.width,“Height:”,test.height) – prints 256, 256
– note: same result if using test:scale(0.5,0.5)[/lua] [import]uid: 5750 topic_id: 4391 reply_id: 13712[/import]
I guess the underlying image remains the same size it’s just drawn scaled. The easy way to fix this is simply calculate the scaled size and use that. [import]uid: 9371 topic_id: 4391 reply_id: 13713[/import]
Yes, but it’s utterly wrong.
If you scale a group you should get the group’s bounding box dimensions in the width/height members of the group.
So, if the image was actually scaled by the group, its bounding box should be re-computed…and the group should hold the new values.
This is just a plain bug. I will test previous versions… but I guess it was actually working. [import]uid: 5750 topic_id: 4391 reply_id: 13714[/import]
Also, you cannot simply hot-fix this in your Lua code.
Say you have all your group objects scaled with the xScale and yScale property… rather than the group:scale() func… then you cannot simply replace a single function. You’d need to rework your thousands-of-lines code! Not feasible.
EDIT:
Also, I’d expect display objects in hierarchy to reflect group scaling, while it’s not:
[lua]local test = display.newGroup(display.newImage(“myImage.png”)) – myImage: width: 256, height: 256
test.xScale = 0.5 – new dimensions for group should be 128, 128
test.yScale = 0.5
print(“Width:”,test.width,“Height:”,test.height) – prints 256, 256
print(“Image Width:”,test[1].width,“Image Height:”,test[1].height) – still prints 256, 256[/lua]
If original texture size is needed, it should be provided separately, i.e. with object.textureWidth and object.textureHeight, as an example. Width and height members should always represent transformed values in screen-space. [import]uid: 5750 topic_id: 4391 reply_id: 13716[/import]
Not sure if you solved this.
Have you tried your_display_group.height vs your_display_group.contentHeight
I don’t think these resolve to the same thing.
Good Luck [import]uid: 27076 topic_id: 4391 reply_id: 28249[/import]
This bug also affects the calculation of xReference and yReference, since scaling isn’t taken into account for the correct width and height. That means the object will be placed in the wrong position after setting the reference point if the object is scaled.
I’m doing stuff like scaling display groups during transitions, and this bug has made it troublesome since I do layout with the top left as the reference point but scale from the center. It means I have to do a lot more bookkeeping to make sure things are in order.
[import]uid: 27183 topic_id: 4391 reply_id: 28449[/import]
Is there a solution to this? I’m having a similar issue - where positioning is being messed up as I have a group that is scaled. I can try to do a reposition based off my scaling, but thats a terrible and inefficient way to solve this. [import]uid: 4289 topic_id: 4391 reply_id: 82492[/import]