Hopefully this helps you get started (see 5_possible_solution ):
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2017/11/jack3.zip
https://www.youtube.com/watch?v=FbOslfG22IM&feature=youtu.be
Jack,
I am having trouble believing that moving objects by moving their parent display group does not work. I use this technique all the time and have never had it fail.
Please make a small sample that demonstrates failure and share a link to it (up upload it) here.
Failing that, make a small demo and paste the code here in a code block and I promise to take a look.
Thanks,
Ed (aka RoamingGamer)
Here’s an example project.
Click the enlarge button twice.
I expand 2 display groups, which do not reposition to their intended places when using a bar because
A. groups do not move and scale as I would expect, so that the rect+bar appears to enlarge from the center, instead the bar repositions and the group calculations no longer put the enlarged version where you would expect, using the exact same calculations as function enlarge1()
B. When you set the value on the bar, the group is resizing according to bar masks, which cause scaling to change dimension calculations. This seems like an oversight, to only allow scaling of multiple items by group, but have the group always have to constrain to a mask (that might vary in position)
While I look at this, let me ask,
“You are aware that groups scale from <0,0> right?”
If you have a 10 by 10 rectangle in a group at position <20,20> and scale the group up, the rectangle will get larger and seem to move right and down.
Note: You and I have very different understandings of the word small.
While I appreciate the example probably too you some time to write, you should not have used composer, added buttons, and it seems tried to demonstrate multiple issues all in the same example.
Nonetheless I’ll try to come up with a answer. However I won’t be using your code as a direct basis. I simply don’t have time to workout the logic of what is going on here.
I put together a sampler with four variations (all in folder groupmove):
ex1.lua - Scaling done wrong.
ex2.lua - Same example with easy fix.
ex3.lua - Your ‘bar’ added to ex2, demonstrating no issues arise from this fix.
ex4.lua - Composer example of ex3.
https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2017/11/groupmove.zip
Jack,
I never did ask, but why do you need to move and scale groups?
Is this some feature in your app, like floating windows or something?
I ask because I hope very much this is not a solution to make your app fit on all devices. If it is, you’re working too hard and I’ll happily show you some examples to deal with making interfaces, etc. fit on all devices.
> I never did ask, but why do you need to move and scale groups?
Characters are drawn as Rects, along with masked bars and eventually buff icons below that.
Scaling is done to indicate an activation (pokemon style), then there’s movement beyond that.
Groups seem like the logical way to deal with a group of graphics that need to be scaled up/down.
Even I am using the same approach but I am also finding it difficult to move object by moving their parent display group.
I’m not sure why you guys are having trouble with this. Groups are a fundamental part of organizing your scenes and creating compound objects.
The main thing is to remember is that groups expand and contract from their center <0,0> so if you want equal scaling and positioning about a point, center your objects around that point in the group.
In the complex case, you use the ‘simple solution’ I gave above in ex3 and essentially find the centroid of the group, then use a second group to position and scale the inner group and that inner group’s children.
What parts in this description are scaled?
- character
- bar
- buff icon
Do you have a drawing of this grouping in its various states? Maybe I can suggest how to group them so you get the scaling you want.
If you can, show me what it should look like, right in the interface, both UNSCALED and SCALED, or if you have a video of a game share a link and tell me what time or times in the video to look at.
A modification to ex3.lua along with fillbar_m.lua allows me to better show how the masking blows out the scaling in a way that I cannot explain, succinctly.
Notice how the bounds of the group are now wider by a strange margin.
If you dive into fillbar_m.lua at ~line 51, you can comment out the mask usage and see how the scaling is not related to the position of the mask, in relation to the tray or fillbar.
Thoughts about Composer -
I do use composer, but I think my approach is better for me.
I save a 1 line per scene/overlay declaring a global in main.lua
s = require(“composer”)
s.gotoScene(“ex4”, {time = 500,effect = “fromLeft”})
So now I wouldn’t have to redeclare require “composer” everywhere.
Roger that. Let me take a look.
Note: Regarding composer… I don’t agree, but you can do whatever you want. It’s all good. I hope you took note of the fact that my scene file splits the will and did events into separate handlers. This makes coding for the phases cleaner and clearer IMHO.
PS - I wasn’t saying don’t use composer. I was saying, don’t use it for a simple example when the question isn’t about composer. It was just more code to wade through, thus more work for me which I wanted to avoid.
I’m confused. I’ve run ex3.lua and ex4.lua and I don’t see any issues.
Which file has the problem?
I only ask, because you included both while only mentioning ex3.
Ah, I think I see what you’re saying. Give me a sec and I’ll post back.
I simplified the example further. Look at:
- 2_theissue - Shows the bounds of the group are ‘oddly wider’ than one might expect… at first.
- 3_theculprit - Shows the cause. Your ‘hidden’ bar is increasing the size of the group.
I don’t have a quick fix for you here.
One fix would be NOT to use the sliding masked content technique for making a bar.
Another fix would be to keep doing it, but NOT to use the bounds of the group for alignment and placement.
If I think of a solution I may post back, but let’s assume you’ll need to resolve the culprit which is that bar sticking out the side of the group.
You probably don’t need it, but I added an alternate bar in this example and hacked the scaling bounds.
The layout of the group will look roughly like this:
I’m sorry, but I need more to work with. I need to know what parts are scaling and how they look scaled.
Are you basing this on a game you like and can you find a a video of this in action?
https://youtu.be/vkmfWzolDfo?t=641
Scaling a character and other elements (like a lifebar) and buffs/debuffs. May have to slow it down to see, but this is an example.