setReferencePoint and STATIC Y value

Solar2D General Questions/Discussion
#1

I’m trying to implement a simple bar graph.
And the state of the graph is animated, meaning that bar’s “grow up” to their full height.

It seems to me that if I:

  1. setReferencePoint of my rectangle to BOTTOM (rec.y = my yAxis)
  2. create a transition that
    a. keeps the Y value the SAME
    b. increases the height over time

Then the bar should just “grow up” to it’s ending height.
But it’s not working that way.

Instead, the bars are drifting down as they grow up…more slowly down than up, but still
Code is below and all suggestions appreciated.

– grow bar to it’s ending height
local rect = display.newRect(60, 300, 20, 10)
rect:setFillColor(100,220,220, 255)
rect.endHeight = 150
rect:setReferencePoint(display.BottomLeftReferencePoint)
curY = rect.y – or tried yOrigin
transition.to(rect, {time=2000, height = rect.endHeight, y = curY} ) [import]uid: 6175 topic_id: 1681 reply_id: 301681[/import]

#2

From what I can tell the Height property assumes the registration point is in the center and adds/subtracts from top/bottom or left/right, which is a bug. It doesn’t respect the value past to the setReferencePoint method.

I was able to make it work by adjusting the Y point:
transition.to(rect, {time=2000, height = rect.endHeight, y = curY - rect.endHeight/2} )

I also had luck using “object.yScale”. This property does follow the setReferencePoint method. The only difference is you will have to compute the height as a scale factor instead of in pixels.
transition.to(rect, {time=2000, yScale = 15} ) – changes height from 10 to 150 pixels

-Tom [import]uid: 7559 topic_id: 1681 reply_id: 4930[/import]

#3

Thanks Tom!! I’ll use your Y method, but this will break when the bug is fixed so can you pass me the bug # (I’m assuming you’ve logged one) and I’ll note the problem in my code.

Well wait…I just tested your Y method and it’s better, but my bars are now floating up proportionately to their endHeight. The situation is better, but they do not remain sitting on my yAxis as I’d hoped? Humm…

We do need much better docs on what all the “Reference Point” is intended to do.
And the docs are still pretty weak with regard to adding/removing whole groups from the stage…I’d love an example of that as well.

Thanks very much for the prompt assistance! [import]uid: 6175 topic_id: 1681 reply_id: 4946[/import]

#4

The yScale method should work and it won’t break when a fix is implemented. I filed the bug as #677 (our internal tracking number).

I agree that the documentation is sparse about reference points and how it all works. We are attempting to provide more API information in between bug fixes and trying to fill out the SDK feature set.

In another thread I wrote about the changes in Beta 7 and removeSelf() method. You can use that to remove groups of objects and it will also remove the group’s children. I’ll see if I can find that thread link.

-Tom [import]uid: 7559 topic_id: 1681 reply_id: 4949[/import]

#5

For reasons difficult to explain, I need to stay with the Y method (over yScale) but I’ve made a few tweaks and now have it working.

I look forward to reading that other post about the stage! It’s unclear to me whether the “removeSelf” method simply takes the display object OUT of the stage-group, or if it DESTROYS the display objects and leaves just a normal Lua table remaining.

I hope your post will clarify that question because I’m still looking for some better examples of managing multiple screens without relying exclusively on the “isVisible” method. I can’t stand the idea of 100’s of objects on the stage simultaneously, and all of them being hidden/shown by “isVisible”. That seems like a very poor implementation to me…especially when you consider native fields who don’t inherit group properties.

So if the display objects (and groups) remain intact after “removeSelf” (it just takes them off the stage), then we need to know how to put them back on the stage. I’m hoping your post will illuminate that as well. [import]uid: 6175 topic_id: 1681 reply_id: 4955[/import]

#6

Here are some postings that may be useful:

http://developer.anscamobile.com/forum/2010/08/12/multiple-levels-and-no-more-removing-objects-potential-performance-issues
Here is a copy of my response to the question about removing groups.
http://developer.anscamobile.com/forum/2010/07/28/error-setting-array-object-nil

@DFox,

In your example, if you do a group:removeSelf(), you will remove all the display rendering elements of “group” and its objects (children). The non-display rendering portions, which includes the Event Listener, is not removed.

The removed display objects (group and children) are converted to simple Lua tables and subject to Lua’s GC (garbage collection). Same thing for the event listener. That means if there is no more references to those variables (tables), they will be GC’d by Lua. The display rendering portion of the objects consumes the majority of the object’s memory and is marked for immediate collection after the removeSelf(). [It should be noted that object:removeSelf() is same as group:remove(object)]

Setting an object to nil may not get rid of it if there is still a reference to the object.

Best practices say that when you remove an object or a group containing objects, you should not reference that group or the group’s display objects again. You should assume it will be GC’d when Lua does it normal collection.

You can safely insert (move) a display object or group from one group to another. You cannot remove a group or object and insert it into another group. That will generate an error because it’s no longer a display object.

I would also suggest removing the Event Listeners before removing the group (in your example). [import]uid: 7559 topic_id: 1681 reply_id: 5334[/import]

#7

I appreciate you guys posting the “Graphics/ReferencePoint2”, example with the new build, but there are a few things that still need clarifying:

  1. which rectangle goes with which reference point should be labeled in the code…you can find out yourself by tweaking the code, but just comment the colors or something
  2. the comment says “-- Notice how the x,y locations for all 3 remain the same!” which they don’t…either it’s an error or your point is not clear
  3. no comment explaining “g:translate( 0, 50 )” – why add 50 to the y coordinate?
  4. there is nothing in these demos that explains what happens when a GROUP has a non-standard reference point and THEN you add other elements to it…in other words, how does the EXISTING referencePoint of the group affect the local coordinates of the objects inserted into it

Thanks for continuing to improve the docs… [import]uid: 6175 topic_id: 1681 reply_id: 5429[/import]

#8

Hi

Is #677 fixed in recent daily builds? I have massive problems setting heights and width on objects that have other ReferencePoints than Center.

  • Magnus [import]uid: 36300 topic_id: 1681 reply_id: 25109[/import]
#9

#677 has not been fixed in the latest daily build. I added a note to the case to try to get it bumped up for a fix in the next release.
[import]uid: 7559 topic_id: 1681 reply_id: 25135[/import]