grossd's Recent Forum Activity

  • Hello,

    I just noticed that when a sprite with move-to behavior is initialized with a negative speed number -- it moves away from the a move-to target.

    However, when max speed is updated once movement towards the target has commenced, then updating the maxspeed to a negative number causes the sprite to stop.

    It seems the interpretation of a initial negative number is to move "away" from the target -- along an inverse vector; whereas once the sprite moves towards the target a negative number doesn't carry this meaning anymore.

    Not sure what to make of this.

    I guess, mathematically speaking having negative speed doesn't make sense, unless speed is a vector, but i think its just a scalar.

    Edit:

    Btw, i couldn't understand why set speed (vs. set max speed) had no effect on the sprite -- when updated after move has commenced -- only an update of max speed caused the speed to change -- not sure why -- its a bit counter intuitive for me --

    Perhaps, its because speed is controlled by the move algorithm, so speed only reports current speed but can't be set, whereas max speed is the max speed the sprite can reach along the vector to the target ... hmm, i guess, that's it.

    • Post link icon

    Hi,

    Thank you for trying this out.

    Try to activate match rotation and use a sprite image where you can see the forward direction.

    You will notice that when you set speed to a negative number and activate matching rotation the sprite image is inverted making it drive backwards.

    • Post link icon

    thanks

    • Post link icon

    Good idea.

    Now that i think of it, its actually a bug.

    First, i thought its a feature request, but i think you are right, its a bug.

    Hmm, where do you file a bug report.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
    • Post link icon

    I just did that work around and, by switching to the horizontally flipped frame, the vehcile doesnt change direction due to negative speed -- however, the frame change is felt visually -- so its not an optimal solution.

    • Post link icon

    Looks like when i enter speed as negative and activate match rotation, then the sprite is turned around -- i.e. the vehicle now drives around in reverse.

    I think this is a side effect of working around the counter clockwise with negative speed.

    Better, if orbit has a dedicated boolean to specify circling direction -- clockwise or counter clockwise -- so that one doesnt need to rely on negative speed.

    I guess one work around is to create two opposite frames -- and upon entering the circle with negative speed switch to the other frame.

    hopefully in the future orbit will get real booleans to specify direction

    • Post link icon

    Yes -- it was overwritten by the code -- i thought it only works clockwise.

    • Post link icon

    hmm, i tried that but it didnt work .. perhaps it was overwritten in the code

    • Post link icon

    Is there a way to make orbit work counter clockwise?

    Tagged:

  • Noticed this pixar video on linear interpolation:

    khanacademy.org/computing/pixar/animate/ball/v/a2-quick

    Looks like what i am missing here is the (formal) math of animation ...

    I can now see how great this math has been packaged into sprite behaviors -- making the accessible with limited such math knowledge ...

    Dan

    Well the bulk of it is a vector projection, so reading a tutorial on vector math may be useful.

    This equation sets t to a normalized vector projection of p onto the line between the two centers.

    t = clamp(((p.x-c0.x)*(c1.x-c0.x)+(p.y-c0.y)*(c1.y-c0.y))/((c1.x-c0.x)^2+(c1.y-c0.y)^2),0,1)

    Combined with:

    targetx = lerp(c0.X,c1.X,t)

    targety = lerp(c0.y,c1.y,t)

    you end up with the point closest to object p on the line segment between c0 and c1.

    If you could do vector math directly in construct it could look like this: 

    A = p-c0 // vector from c0 to p
B = c1-c0 // vector from c0 to c1
t = (A dot B)/length(B)^2 // normalized vector probjection
t = clamp(t, 0, 1) // limit to the line segment
closetPoint = c0 + B*t // get point by lerping between c0 and c1 by t

    So anyways, you get a point between c0 and c1 close to p.

    Next it moves p toward that point so it's exactly a 'radius' away.

    Then it turns p left 90 degrees and moves forward at "speed" pixels per second.

    Honestly it's just a bunch of simple things put together. I usually draw a picture as i go coming up with these things. Then i simplify the math as much as possible.

    You could google things like "vector projection" and "point closest to a line segment" to find more info about the math.

    The construct specific stuff:

    clamp(value, low, high) limits a value to be between a low and high value

    lerp(a, b, t) moves a percentage from a to b by t. Where t is between 0 and 1.

  • Honestly it's just a bunch of simple things put together. I usually draw a >picture as i go coming up with these things. Then i simplify the math as much >as possible

    Simple for you :-)

    I feel like i am only getting to see the projected vector, and not the original one, and why projecting a vector is in fact a solution for identifying the path over time.

    Also the 90 degree turn that happens every tick is completely opaque to me -- there is no turning happening visually -- and interesting, when i set it to -90 the movement is reversed! -- holy cow -- how did that happen :-)

    I also like to work things out by drawing the out geometrically in powerpoint -- but, my trig. is rusty, and now, apparently, i need to get into vec again -- which is even more rusty :-)

    Dan

  • Hi,

    This is great.

    I am looking to analyze how exactly it works -- and why, when orbit is enabled, it doesn't arbitrarily displace the sprite, but keeps it going on the right path / (tangential) turn around the edge.

    How would you extend this solution to have a road coming into the track, where, for the first time, the sprite travels down the road to the track, does a first full "hello" round, and then continues on around the track,as its now.

    I am curious if orbit can be configured for such an initial behavior as well, in particular, when the incoming road could have any kind of angle.

    Can this be done?

grossd's avatar

grossd

Member since 4 Feb, 2014

Twitter
grossd has 1 followers

Trophy Case

  • 12-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

17/44
How to earn trophies