•      Sign In
• Create Account

### #ActualKhatharr

Posted 15 February 2013 - 04:19 AM

Those functions are placing the sprite in the location of the destination tile. Whatever you have that determines where a specific tile position is on the screen, those functions should return a pixel x/y in terms of the screen based on the map tile x/y passed in. Immediately after that the sprite gets placed in this position it gets 'backed up' to its interpolated position between the destination tile and the origin tile.

FRAMES_FOR_SINGLE_TILE_MOTION would be the 'duration' that Spiro was telling you about. The number of frames it takes to walk from one tile to the next.

STEPPING_FRAME_DISTANCE would be the number of pixels traveled in one frame.

So if you had 32-pixel wide tiles and you want to make the trip in 8 frames then FRAMES_FOR_SINGLE_TILE_MOTION would be 8 and STEPPING_FRAME_DISTANCE would be 4, which is 32 divided by 8.

So say you're on a tile and you start a move to the left.
Your tile position gets changed and:
pendingMotionFrames = FRAMES_FOR_SINGLE_TILE_MOTION; //8
The sprite facing gets changed (which is not in the code) but the sprite is not moved yet.

Next frame:
pendingMotionFrames is reduced to 7
int positionOffset = pendingMotionFrames * STEPPING_FRAME_DISTANCE; //7 * 4 = 28
sprite gets moved to the target tile, it's facing is still leftwards
since it's facing leftwards sprite.x -= positionOffset, so the sprite gets moved back by 28 pixels. It's effectively moved 4 pixels from its starting tile.

The next frame pendingMotionFrames is reduced to 6, so positionOffset will be 24. The sprite gets put on the destination tile and then moved backwards 24 pixels. It now appears to have moved 8 pixels.

This repeats until pendingMotionFrames gets set to zero. The sprite will get placed on the destination tile, but positionOffset will be zero, so it will stay put there and the movement is complete.

This is just a different way of implementing the same interpolation Spiro-sama was telling you about. She's discussing it in a more general sense. The method I'm talking about is specific to the type of game you're working on. You should really look into what she's talking about and learn the general case, then try to see how that's implemented in what I'm talking about.

### #1Khatharr

Posted 15 February 2013 - 04:16 AM

Those functions are placing the sprite in the location of the destination tile. Immediately after that the sprite gets 'backed up' to its interpolated position between the destination tile and the origin tile.

FRAMES_FOR_SINGLE_TILE_MOTION would be the 'duration' that Spiro was telling you about. The number of frames it takes to walk from one tile to the next.

STEPPING_FRAME_DISTANCE would be the number of pixels traveled in one frame.

So if you had 32-pixel wide tiles and you want to make the trip in 8 frames then FRAMES_FOR_SINGLE_TILE_MOTION would be 8 and STEPPING_FRAME_DISTANCE would be 4, which is 32 divided by 8.

So say you're on a tile and you start a move to the left.
Your tile position gets changed and:
pendingMotionFrames = FRAMES_FOR_SINGLE_TILE_MOTION; //8
The sprite facing gets changed (which is not in the code) but the sprite is not moved yet.

Next frame:
pendingMotionFrames is reduced to 7
int positionOffset = pendingMotionFrames * STEPPING_FRAME_DISTANCE; //7 * 4 = 28
sprite gets moved to the target tile, it's facing is still leftwards
since it's facing leftwards sprite.x -= positionOffset, so the sprite gets moved back by 28 pixels. It's effectively moved 4 pixels from its starting tile.

The next frame pendingMotionFrames is reduced to 6, so positionOffset will be 24. The sprite gets put on the destination tile and then moved backwards 24 pixels. It now appears to have moved 8 pixels.

This repeats until pendingMotionFrames gets set to zero. The sprite will get placed on the destination tile, but positionOffset will be zero, so it will stay put there and the movement is complete.

This is just a different way of implementing the same interpolation Spiro-sama was telling you about. She's discussing it in a more general sense. The method I'm talking about is specific to the type of game you're working on. You should really look into what she's talking about and learn the general case, then try to see how that's implemented in what I'm talking about.

PARTNERS