To continue where I left off last time I found the following formula on wikipedia, which can be used to determine where two lines cross, I used this to determine where the players trajectory and the edge of the tile cross and therefore the point that the player leaves the tile.
As I plan on using this in multiple places I created a function which takes the start and end points of two lines and returns the position that the two lines intersect.
I know some people do not like putting TODOs in comments but for me it is a great way of keeping in the flow of coding without forgetting some of the smaller things which I can see will need tidying up or fixing.
As can be seen in the comments above, this function does not check if the lines are parallel, there would be a division by zero if they were, which would crash the application, but as the function is only called to get the intersection point after checking that the two lines intersect, I shall add a TODO in the comments to remind me that there should be a check in for 0.0 value divisor.
Also in the comments I have put a TODO to remind me that for this function it would make more sense to create a 2D version of
Position3Float and use that instead of
This is where things got complicated, so far I have only catered for the player moving up, down, left or right and not diagonally in any direction.
The general flow of processing the player movement goes like this:
Hopefully the comments explain what each variable here is for, some additional things to note are:
distanceTravelledmust be set to anything except 0.0f otherwise the next loop will never be entered.
endPositionis used to make up the returned position, setting it to the start position means if anything goes wrong the player will not move at all.
This loop repeats while the player can still move and is still moving.
This takes the remaining distance and applies the fluidity of the current tile to work out how far the player will travel along this tile, it then multiplies the distance by the normalised direction vector and adds it to the start position to calculate where the player would end up.
This code is similar to the existing code for checking for tile changes.
This is performed in a big when statement to allow each direction to be separate, at the minute, because I have not coded the diagonal transitions yet, the process is similar for each direction:
- Calculate where the players trajectory intersects the edge of the tile.
- Calculate the index of the tile the player is moving to.
- If the tile the player is moving to has a non 0.0 fluidity value then the
endPositionwill be where the player intersects the tile edge - the tile size to wrap around to the opposite side of the tile like we did in the previous code. The
currentTileis also updated as the player has now transitioned to this new tile.
- Otherwise the
endPositionwill be where the player intersects the tile edge.
This does give a slight overlap between one tile and the next, e.g. any point at the edge of one tile is also technically on the edge of another tile as well.
Whether this is of any consequence remains to be seen.
One thing that may be confusing is how
intersectionPoint differ, if the player is on the same tile then they both have the same value, when the player enters a new tile the
endPoint is where the player entered the new tile and the
intersectionPoint is where they left the old tile.
If the tile which the player is on has changed, the center tile is updated to be the new tile and all other tiles are reset based on this new center tile.
Then all the tile offsets are reset as before.
This update took me a while to get motivated to start but once I did it came together quite nicely.
I should now be able to create a complete level which the player can move around consistently.
The code at this point of the project can be found here.
Stay Safe and Happy Coding.
Until next time,