search

leftiness / hex_math

MIT License
4 stars 1 forks source link

Make a better get_step_direction() #63

Open leftiness opened 7 years ago

leftiness commented 7 years ago

RIght now, I've got a util::get_step_direction() in line.rs. It works by subtracting p1 - p0, getting the positive/negative sign of the QRT, and making a basic guess about direction.

I want a better one.

Using p0, p1, and origin (0, 0, 0), I can do some trig to determine what the direction of p0>p1 is properly. Remember to convert to PixelPoint before doing the trig.

Maybe do something to decide whether to call the direction "up" or "east." If it's really, really far up and one hex east, then that p0>p1 direction should be called up. Once you reach a place where they're about equal, then you can alternate between east and up. I guess favor east just because you have to favor one or the other.

This function should probably be like Direction::from((&Point, &Point)).

leftiness commented 7 years ago

That function is in Direction::from now.

leftiness commented 7 years ago

The current function actually barely works. He only works if he's dealing with neighbors that have a distance of 1.

Sometimes you have a scenario where your (q.signum(), r.signum()) is (1, 1). You're southeast AND east. Not just one or the other. I didn't do anything about that. Example: QRST (0, 0, 0, 0) -> (1, 1, -2, 0).

I could fix that by adding more signum checks. Then I could just favor certain directions if both are an equal option. At present, I favor up/down before even checking if it could be east/etc. Not very good.