basic UI layout - Group, Container, or Snapshot?

Solar2D Advanced Graphics
#41

Ingemar - why would you want to do that exactly? Does the boundary update when you move sprites? I can see all sorts of weirdness going on.

Seems like a very odd extra function to use - you can set up a ‘fake’ anchor point in a group just by positioning the children correctly.

Looks like I’ll just ignore it really - after all I still have issues with anchor points because (1) they don’t work in pixels and (2) you can’t move them outside of the boundaries. So, I’ll just keep using nested groups which gives the same functionality plus more I suppose :s

#42

That’s very true.

#43

@rakoonic - what did you mean by “positioning the children correctly” in fact? 

The main issue I think is that with groups if you align the group based on it’s position, things could screw up if you added another object to the group say that was above and to the left of any existing objects in the group.  So (thinking out loud) you need (a) an easy way to position the group in it’s parent group, but also (b) know that if you do add additional objects to groups that this won’t change/screw up the layout.  Perhaps you suggesting one positions the group within it’s parent group by reference to one of the children of the group?

#44

Before G2.0 you had groups.  Groups had no width or height, so they never worked with reference points.  Groups did have a faux center, called it’s origin point, which is 0, 0 and by default that is located at 0, 0 on the screen.   If you could use groups before for building UI’s, grouping things and moving them together, you can still do that in the exact same way.   You didn’t have Anchor Points or even Reference points with groups before, so not having them now is the same thing.

You can also still apply masks to groups to get container like effects too.

#45

thanks for chiming in Rob - you’re right that I had some challenges before G2.0 so will continue to have them now in the same sense then.

Rob, can I ask for your advice here, in terms of moving forward with what we have.  Mainly:

i) do you understand where I’m coming from re looking for (a) an easy way to position the group in it’s parent group but also (b) know that if you do add additional objects to groups that this won’t change/screw up the layout?  Perhaps I’m missing something…

ii) what would recommend as the best approach to use right now that covers off point a) and b) above? 

#46

There’s not a lot of magic going on here, and (unless you’re migrating) it’s pretty easy to determine how containers (and anchorChildren=false) work and write new code accordingly.

The anchorChildren=false works like a champ (a sage corona addition IMHO - it melds containers and groups together well)… I’ve used it, and the container insertions acted like I would have expected group insertions to (in my case with a bg graphic and a few dozen other object placed around in random spots). And like Rob said, you don’t have to use containers at all. Just stick to the old fashioned way - groups and masks.

[lua]

    local c = display.newContainer(640,960)    – 640x960 is my config lua content size
    c.anchorChildren = false
    
    c.anchorX = 0.0  – top left of contatiner
    c.anchorY = 0.0        

    c.x = 0   – top left of screen coord
    c.y = 0    
 

    – insert things now… they’re where I expect…

    – AND everything is clipped to the container bounds… (can make it wider/taller for bleed if you want…)

    local Background = display.newImageRect(“Bg02.png”,640,960)

    Background.x = 320 – image origin is it’s centerpoint, so image is centered onscreen
    Background.y = 480
    c:insert(Background)
 

    – etc etc

[/lua]

#47

> If you could use groups before for building UI’s, grouping things and moving them together, you can still do that in the exact same way.

Same way? Kinda. You now have to translate each displayObject that was added to a group like so:

displayObject:translate(displayObject.width/-2,displayObject.height/-2)

I’m using a utility g2xlate function to pick through my code and strategically update elements that need it.

You also need to add group.anchorX = 0, group.anchorY = 0 for the exact same nested group/mask behaviors.

For complex objects using 3rd party libraries (like x-pressive) … good luck! I haven’t gotten that far.

#48

@jack95 - I think you can just set default values for the anchor points (display.setDefault( “anchorX”, 0 ) I think off top of my head).

@Greg - I was referring to the fact that if you want the ‘reference point’ (or in this case, group origin) to be in the middle of all your objects, I’d just place the objects either side of the origin, and use it like that. For more complicated origin needs like rotation groups etc, I just used nested groups, which IMO is still going to be more flexible than anchor points as you can place the rotation / scale point anywhere, not just within the bounds like anchor points.

#49

@rakoonic

display.setDefault( “anchorX”, 0 )
display.setDefault( “anchorY”, 0 )

These setting do not apply to all child groups. At this time (since .2085) I must assign anchorX and anchorY individually, even with these set.

#50

Ingemar - why would you want to do that exactly? Does the boundary update when you move sprites? I can see all sorts of weirdness going on.

The problem I have is with the name anchorChildren. It might be just me, but my brain doesn’t process the term since it doesn’t modify the behavior of the children per se.

Regardless of if anchorChildren is true or false, adding objects to the group will still use the children’s common anchor point to position them relative to each other.

The only time anchorChildren comes into play is when you want to position the group on the stage. 

When anchorChildren=true, the group will get its own anchor point which you can set like with any other object. This makes it easier to position if you have groups where the children’s common anchor point is at an arbitrary position.

When anchorChildren=false, the group’s positioning will be using the children’s common anchor point which may prove to be tricky to position the way you want.

To me the term anchorGroup=true makes more sense than anchorChildren=true as the ultimate effect of setting this property affects the group’s positioning, not the children.

#51

@ingemar - great last post - really helped clear things up for me…