Corona ignoring Reference Point when transitioning??

Solar2D General Questions/Discussion
#1

Hey folks,

I’ve come across some weird behaviour, and was wondering if anyone else has experienced anything similar, and can maybe suggest a workaround?

I am trying to implement a simple custom progress bar, consisting of a single rectangle, which, using transition.to(), expands its width to the required size to indicate the progress so far.

Simple. You would think.

Here is the simplified code, for the purpose of demonstration.

local progressBarWidth = 300  
local progressBar = display.newRect( 0, 0, 0, 15 )  
progressBar:setReferencePoint( display.TopLeftReferencePoint )  
progressBar.x, progressBar.y = 40, 30  
progressBar:setFillColor( 255,0,0 )  
transition.to( progressBar, { delay = 1000, time = 500, width = progressBarWidth, transition = easing.inQuad } )

The progress bar is set with a reference point of TopLeft, but as the width increases during the transition, the bar expands both left and right, as if it has a Center reference point.

huh?!

Any ideas? :-s [import]uid: 60457 topic_id: 34848 reply_id: 334848[/import]

#2

This is a known limitation of .width and .height (Docs) To be honest I had no idea .width was even writeable!

The workaround (and the way I build meters) is to use .xScale (or :scale(x,y)) This requires some math because you need to figure out what the xScale you need to reach is for a given percentage of the meter width, but it’s doable. (It’s also easier to do the scaling math if your meter starts out at 1px wide, because .xScale would then basically == width)

Keep in mind that if you change the .xScale or .yScale of an object, it will still report the original width or height before you scaled.. If you need to measure the width of a scaled object, you can calculate it.

local width = object.contentBounds.xMax - object.contentBounds.xMin
#3

Here’s sample code based on Richard’s suggestion:

local progressBarWidth = 300 local progressBar = display.newRect( 0, 0, 1, 15 ) progressBar:setReferencePoint( display.TopLeftReferencePoint ) progressBar.x, progressBar.y = 40, 30 progressBar:setFillColor( 255,0,0 ) transition.to( progressBar, { delay = 1000, time = 500, xScale=progressBarWidth, transition = easing.inQuad } ) [import]uid: 200026 topic_id: 34848 reply_id: 138494[/import]

#4

I had the same issue. I didn’t end up using scaling though, I just used some simple math to adjust the X attribute in relation to the new width (or in my case height). Just add X to the transition like below.

local progressBarWidth = 300 local progressBar = display.newRect( 0, 0, 0, 15 ) progressBar:setReferencePoint( display.TopLeftReferencePoint ) progressBar.x, progressBar.y = 40, 30 progressBar:setFillColor( 255,0,0 ) transition.to( progressBar, { delay = 1000, time = 500, x=progressBar.x+(progressBarWidth/2), width = progressBarWidth, transition = easing.inQuad } ) [import]uid: 56820 topic_id: 34848 reply_id: 138510[/import]

#5

This is a known limitation of .width and .height (Docs) To be honest I had no idea .width was even writeable!

The workaround (and the way I build meters) is to use .xScale (or :scale(x,y)) This requires some math because you need to figure out what the xScale you need to reach is for a given percentage of the meter width, but it’s doable. (It’s also easier to do the scaling math if your meter starts out at 1px wide, because .xScale would then basically == width)

Keep in mind that if you change the .xScale or .yScale of an object, it will still report the original width or height before you scaled.. If you need to measure the width of a scaled object, you can calculate it.

local width = object.contentBounds.xMax - object.contentBounds.xMin
#6

Here’s sample code based on Richard’s suggestion:

local progressBarWidth = 300 local progressBar = display.newRect( 0, 0, 1, 15 ) progressBar:setReferencePoint( display.TopLeftReferencePoint ) progressBar.x, progressBar.y = 40, 30 progressBar:setFillColor( 255,0,0 ) transition.to( progressBar, { delay = 1000, time = 500, xScale=progressBarWidth, transition = easing.inQuad } ) [import]uid: 200026 topic_id: 34848 reply_id: 138494[/import]

#7

I had the same issue. I didn’t end up using scaling though, I just used some simple math to adjust the X attribute in relation to the new width (or in my case height). Just add X to the transition like below.

local progressBarWidth = 300 local progressBar = display.newRect( 0, 0, 0, 15 ) progressBar:setReferencePoint( display.TopLeftReferencePoint ) progressBar.x, progressBar.y = 40, 30 progressBar:setFillColor( 255,0,0 ) transition.to( progressBar, { delay = 1000, time = 500, x=progressBar.x+(progressBarWidth/2), width = progressBarWidth, transition = easing.inQuad } ) [import]uid: 56820 topic_id: 34848 reply_id: 138510[/import]

#8

Thank you, guys. :slight_smile: [import]uid: 60457 topic_id: 34848 reply_id: 140067[/import]

#9

Thank you, guys. :slight_smile: [import]uid: 60457 topic_id: 34848 reply_id: 140067[/import]