A matter of perspective...

mhedgesmhedges Raised on VCSMember Posts: 634
edited August 2016 in Working with GS (Mac)

Hello -

I hadn't posted in a while. Busy with a lot of real world stuff again.

As the title suggests, the topic is perspective. In a 2D world, I have a top-down view of two actors which move from the left side of the screen to the right side of the screen. Pretty simple.

In a pseudo-3D world (we just want to create the illusion of perspective) there is a horizon and a vanishing point. Both actors start at the same line, will move at the same speed, and reach the other line simultaneously.

What formulae would I be looking for to ensure that the 2D behavior is replicated in the image seen above?

For example, I understand that to make it work, actor B has to move faster than actor A to provide a feeling of perspective, and if I add another actor, the same would apply, and so on.

I can see the triangle formed by actors (points) a and b, and (invisible) c has a right angle. Would I be applying Pythagoras' theorem? If so, how?

Comments

  • NNterprisesNNterprises Member, PRO Posts: 387
    edited August 2016

    I would just use interpolate. With interpolate position.x, you do it by TIME, so the speed will automatically be different if it is different distances, but they will get there the same time.

    Distance = speed x time

    Interpolate A.position.x to Q at TIME seconds
    Interpolate B.position.x to Z at TIME seconds

    No matter what seconds you put in it will always arrive at the same time

  • SocksSocks London, UK.Member Posts: 12,822
    edited August 2016

    Like NNterprises interpolate has a fixed travel time, so that would be the easiest way.

    If you wanted to use something like 'Move' or 'Linear Velocity' (where speed to specified rather than travel time) - then simply make the speed a function of the Y position.

    For example if you are spawning rocks on the floor, moving right to left, and want them to move in perspective . . . .

    A: Decide how fast you want the rocks at the horizon to move - usually slowly but not 0.
    B: Note the upper Y range of the rocks (e.g they are spawned randomly y=(0,300))

    ((A+B)-self.Y)*speed multiplier

    Hold on . . . demo time . . .

  • SocksSocks London, UK.Member Posts: 12,822

    Example attached . . .

  • mhedgesmhedges Raised on VCS Member Posts: 634
    edited August 2016

    @Socks,

    That looks very promising. Thanks to @NNterprises for the input, but I didn't mention that I believe the Interpolate behavior does not work well with collisions, something I didn't point out earlier simply because I didn't disclose anything concerning collisions.

    EDIT: Using Interpolate, X does in fact get destroyed if it collides with an actor I added to the scene.

  • mhedgesmhedges Raised on VCS Member Posts: 634

    Close to figuring it out. I'm currently moving the objects at (100/(self.position.y/horizon)).

  • mhedgesmhedges Raised on VCS Member Posts: 634
    edited August 2016

    After giving it a bit of thought, for now, since I would know the distance when drawing the lines and determining the horizon's y, and determine how much time it would take from one line to the other, then I can compute the speed.

    I want(ed) a more automated approach, as I would like to have actors on a grid move in perspective a la space invaders or galaxian, but with perspective. Every actor would have the same code (revert to the prototype). This is not required in my unfinished symphony, which will be (if published) a car racing game.

  • NNterprisesNNterprises Member, PRO Posts: 387

    @mhedges said:
    After giving it a bit of thought... I can compute the peed.

    lol typo

    But just so you know, Move, linear velocity and those things are all time related too.
    So if you move or have a velocity of 300, it will move 300 pixels per second.

    So doing some math you can create a self attribute called speed and make them move at those speeds until collision with the horizon line.

    At the top of your actor, make a rule saying:
    Change speed to (End horizon - Start)
    End and start may have to be self attributes too...

    Actually that may be all you need now that I think about it

    Because for A it would move like 100 pixels/second (slower) and the B would be like 200pixels/second but they should get there at the same time

    Maybe? It seems too easy

  • mhedgesmhedges Raised on VCS Member Posts: 634

    @NNterprises said:

    @mhedges said:
    After giving it a bit of thought... I can compute the peed.

    lol typo

    Thanks. Almost speed when I saw this! :D

    Yeah, I need to find some "modular" formula; there has to be an elegant solution. I'm currently drawing out a model to have a visual representation of endpoints I may consider.

  • NNterprisesNNterprises Member, PRO Posts: 387

    lol but yea the speed thing I suggested should work but you would have to somehow get the X points of the horizon lines. Also possible with math on math if it's a straight line.

Sign In or Register to comment.