I have two mobs standing a couple of turfs apart. They both have a pixel x/y offset on their turf. I know both the offset and the "real" x/y coordinates, ((turf.x-1) * 32 + mob.pixel_x), and of course the turf/mob location on the map. Now I would like to find out the following in a nice quick fashion:
- If you draw a straight line between the mobs from their exact location, which turfs does this line intersect? Should be simple, but I want it optimized!
- A bit more tricky: For every turf that the line intersects, I want to know where the line crosses a turf border, and returns the coordinates of that position, relative to the turf it's crossing at the moment. Something like:
+-----C-+-------+ | \-B__ | | | \ | | | -A | +-------+-------+ A = The mob B = I want the coordinates of this position, in this case something like (1,28) C = This position too, since the line keeps going...
I have most of it figured out myself, but I would like to discuss the way to do it best. The reason for problem 2 is of course that I would like to use DrawBox() to draw a line between two points. So, any ideas?
/Gazoot
From here we need a few conventions. For simplicity's sake, let's call the lower left corner of each turf 1,1 and the upper right 32,32, icon style. By convention, an obj or mob at pixel offsets of 0,0 is at position 17,17.
Now I'll need two distances in pixels: pxd and pyd, both measured as atom2-atom1.
I'm hoping I didn't screw any of that up, though likely as not I did. As you can see this is a pretty complex problem. The algorithm as it stands will correctly skip over a diagonal gap from one turf to another if need be. The part I did not show is where you repeat this for abs(pxd)<abs(pyd), swapping all the x and y vars except in the order they're put into PushToList(). (You'd still switch x and y for the second pair of coordinates, but then you'd have to swap their order so the new x comes first.)
I suppose in theory it's possible to do this with lists in a way that doesn't require quite as much complexity in the var names and could perhaps reduce the complexity of the algorithm, but it may or may not be an improvement. In that form, you'd have a single list storing alternating copies of px1,py1, tx1,ty1, dirx,diry, jx,jy, etc. An index could point to the main direction's offset in the list, while another points to the secondary direction. Baiscally you'd be swapping one form of complexity for another if you did that.
Lummox JR