How do I adjust one side of a square object independently?

I have a small 50 x 50 box (Scaled down) and when it is tapped it's position should stay the same and it should adjust in size to fit the Viewport, or seemingly do so. When the player is done the box should adjust back to it's original size and position. I only know how to move boxes and adjust width equally on both sided as well as height. I am unaware of how to adjust each side of the square according to it's potion within the Viewport. I was going to use Lerp for this, but I just don't know what to use for the box's edge or points. I am aware of Viewport Top, Left, Right, Bottom.

The box is just a solid color.

You can adjust width and height separately in your object actions. Instead of change "size" just look for "width" or "height" only to apply just one or the other. Is this what you mean?

~Sol

No. I know of that, the box isn't gonna be in the middle of the screen. It would look correct when it expands out but when it contracts it won't look correct. There would be a lag on the side that is closest to the edge of the Layout.

I will probably have to use width and height and adjust the box's position when it is scaling down. I wish there was an easier way though.

You can just lerp the size and position. It won't matter if it's in the middle of the screen or not - but if you're filling the entire layout/viewport with it then it will end up in the middle anyway.

If you lerp the width and height to the size you want, and lerp the position from it's "normal position" to "viewport center" then it should do what you want? I guess it depends on how you want it to behave though.

~Sol

That is what I have been trying to do. For some reason I am having trouble with it. Instead of going to it's expanded size it treats the third number as a % (as it should) but it only moves once. As in if I have it at 0.5(or 0.1) it instantly makes the object 50%(or 10%) of the size it is supposed to be and it stops expanding. I thought maybe Time Scale was effecting it because I have Time Scale set to 0 when this is happening. I disabled the trigger to set Time Scale to 0. When Time Scale is 1 it still does the same.

I am sure it is the way I structured the events. I am needing an example of a box sprite expanding in size when clicked and contracting back when clicked again, or the conditions that should be used. I wanted it to be a function so it skips unneeded events unless clicked. I thought that may be the reason so I tried otherwise and it acts the same. It needs to be unaffected by Delta Time.

Thank you.

I found my error...

On lerp I had:

lerp(50, 800, 0.3)

I changed it to:

lerp(Object.Width, 800, 0.3)

I think it was interfering with itself, I should have noticed that rather quickly... opps.

Not really.

You did't change that '0.3' each tick, and therefor you got one value in return.

The lerp should be lerp(50, 800, 0>1), where '0>1' is a value that counts from 0 to 1 in a time you choose.

The solution you found is kinda a 'fake' solution. It works, well kinda, that lerp will never reach 800.

It works because the distance between 'Object.Width' and '800' gets smaller.

If you cant wrap your mind arround 'lerp' then maybe you better use LiteTween.

Just a friendly suggestion.

I don't fully understand

"You did't change that '0.3' each tick, and therefor you got one value in return."

I tried litetween before I posted this post. 'Time Scale' seemed to be interfering with it. I couldn't find anything in the manual or post about 'Time Scale' or "Delta Time'. I got it to work correctly but there was a delay in the 'Time Scale' variable change and I can't have that. The change has to happen instantly.

I understand how lerp works mathematically. It is actually very simple. It takes two values and finds the difference using a 0>1 number as a percent. 0.5 will take 50% off of the remaining difference until it can't any more. 100, 50, 25, 12.5 , 6.25, 3.125....etc

lerp(50, 800, 0.3) is only returning one value no matter where I put it.

The only logical thought I came up with is it is running lerp correctly but since it isn't getting a reference to the object itself it is always returning the same value.

I had it under a variable = 1 condition with and without 'Every Tick'

I had it by itself with no Condition with and without an 'Every Tick'

I am using 'Set Size' where it sets width and height at the same time.

I even tried doing 'Set Width' and 'Set Height' individually and it is only returning one value.

It just isn't working, it always returns one value.

I understand lerp(Object.Width, 800, 0.3) never reaches it's target.

It is why I put in a condition to fix it.

I've spent way to much time trying to make it work.

What I did made it work and it looks correctly when adjusting it's size and position.

I had to do this with "Set Position" as well.

I will gladly fix what I have if I can find an example Capx or if someone can point out why lerp(50, 800, 0.3) isn't working.

I can't find an example of someone not placing the first lerp value of something related to the object. The first lerp value is always object.X or object.Y in all of the examples I have found. I also can't find an example of someone using lerp to change the size of an object. I can only assume it is similar to moving an object with lerp.

'0>1' means that it needs some coding like this (very basecaly):

Global variable .. number ... = zero.

Every tick > add 0.1 to number (with max 1 and a reset for the next lerp)

lerp(50, 800, number)

Now number steps from 0 to 1 in 10 steps and the lerp will got from 50 to 800 in 10 steps.

It is as easy as that !

What you do now is the equvalent of lerp(number,800,0.3)

I have a small 50 x 50 box (Scaled down) and when it is tapped it's position should stay the same and it should adjust in size to fit the Viewport, or seemingly do so. When the player is done the box should adjust back to it's original size and position. I only know how to move boxes and adjust width equally on both sided as well as height. I am unaware of how to adjust each side of the square according to it's potion within the Viewport. I was going to use Lerp for this, but I just don't know what to use for the box's edge or points. I am aware of Viewport Top, Left, Right, Bottom.

The box is just a solid color.

TragusInfantigoRx

That sounds me a lot!

Unconnected I believe what you are doing is correct. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

99Instances2Go Isn't what you suggested just moving it at a constant speed? and therefore defeating the smoothness that lerp is typically used for? I mean.. what you said is useful, too. but when people around here ask for lerp, I usually assume they're looking for the smoothy version.

EDIT: Found this: https://www.scirra.com/blog/ashley/17/u ... delta-time

Your assuming is as good as mine.

I assume that poeple who ask how lerp works, ask how lerp works.

Lerp, when used with a liniair lerpfactor, wil indeed move at a liniar speed. So yes, you are right.

But, lerpfactor can as well be sqrt(abs(counter – 1)) ... where 'counter' goes from 0 to 1

Lets split things up. Lerp can (indeed) in two ways.

Method 1.. lerp(StaticStart,StaticEnd,DynamicFactor)

Method 2.. lerp(DynamicStart,DynamicEnd,StaticFactor)

Method 1 is (in my opion) the base-lerp, the base to learn.

Awesome to do grid movements, by instance. Base means also that it has no 'side effects'. It works as intented. And it is very easy to use.

Method 2 is (in my opion) a version that brings problems that have to be countered. Yet, you will have to use it when Start or/and End has a dynamical character. Not because of the smooting. In my opion that is mis-use. And yes it smooths, but more by accident, than intended. But you will have to take care of the problems.

Dynamical character ? When lerping a moving sprite to a moving sprite.

(In the above given situation Start and End are not dynamical)

What problems you will meet ? (you suggest to use this method, but dont tell about the problems)

Well,

The lerp will never ever arrive to its endpoint. Causing all sort of problems, that fill the forums. When lerping a camera, the camera will start shaking when the lerp is close to its end.

When close to the End, the value returned by the lerp will change in very very small amounts. Since positions and angles are always 'calculated values', this will result in randominess on sub pixel level. You see shaky sprites.

Most people use 'lerp' in a 'every tick' event. But since this lerp never arrives, and since the calculations get slighty heavyer, this lerp will just run every tick and it will eat noticable CPU.

That are my 10 cents, dont know the exchange rate.

Well said. I almost completely agree with you. But agreeing doesn't give us anything new to talk about.. so...

Well.. he said he had worked around the ONE problem (you kinda gave it a few labels, but it's still the same problem) that is caused by that. and it really isn't very hard to work around, so I didn't mention it. but yes, it does come with that problem.

I don't think either use is more proper than the other without being specific as to what the intended result is. In my mind, using lerp the way you suggested seems extraneous when there's so many built in ways to have things move or change size at a constant rate, which, I think, is why most people here in C2 land are using it for the smootherism.

I mean.. obviously the smoothing is not by accident.. tons of games and applications (big and small) use it that way.

Using it 'every tick' outside of ticks where you actually need it is obviously a whole other issue and would apply to either method..

That's only 2 cents from me. That's all I've got to spare (the exchange rate is not great...)

spacedoubt, you see what i mean ?