1
\$\begingroup\$

Currently, I have a bitmasking implementation that sometimes incorrectly bitmasks the tiles. Conventionally, it is done correctly, and the math/etc is sound, but it achieves results such as the following:

Diagonal crossing 2nd Diagonal crossingParallel crossing

This is similar to what you might expect, and looks fine when doing simple x-shaped crossings. However, I would like for the images to remain unchanged in some of these cases. For instance, the parallel paths in the third image would remain parallel paths instead of being bitmasked into many crossings. In the first and second images, only the parts of the path highlighted in the following images would be bitmasked (Different parts of path labelled for clarity.)

Revised version of 1Revised version of 2

If I purely update only the tiles that make up the newest path, I again get good results in simple x-shaped crossings, however I get results such as those demonstrated in the following image:

Rev2 Diagonal crossing

What could I do to achieve results where this would not occur? I have though about adding some sort of flag to the tile to indicate that it is a crossing, but how could I detect that?

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ A "crossing" has the property that it first enters collision with the other path, and then leaves. So go along the path from the start to the end, and keep track of whether you've intersected another path. You will have a crossing at points where the path begins intersection and ends. \$\endgroup\$
    – mklingen
    Apr 7, 2015 at 21:23
  • \$\begingroup\$ @mklingen please, answer :). I'll try this out later, but if you elaborate a bit this could definitely be a viable solution. \$\endgroup\$
    – Pip
    Apr 7, 2015 at 21:46

1 Answer 1

Reset to default
3
\$\begingroup\$

You draw out your first path, and it has no knowledge of other upcoming paths. Once you draw your second path (overlapping the first) you need to update your first path again, so that it knows about the second path.

This is just a bad way of doing it. A better option would be to draw out all your paths first, and then check the neighbors in a second pass to instantiate your bitmasking. Otherwise, you are going to have to update all trails everytime you create a new trail (which could also be a solution for you, albeit a little slower).

EDIT

Ok, so I understand now that you don't want some of the paths to intersect. You should try to give each path an ID, and then check if your surrounding tiles are from the same path or not.

If they are not from the same path, then you would not include it in your bitmask calculations. However, if the tile is crossing over another path, then you would include them, as at this point you would want them to connect.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ The latter is a solution that I already attempted, and it was much too slow to achieve. My problem here is not that the first path is not updated, but rather that the second is being bitmasked in a way that I do not want. \$\endgroup\$
    – Pip
    Apr 8, 2015 at 11:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .