To respond to those issues quickly:
1) While I might not necessarily rule out decimal support for step_x/y for the future, at present they are not implemented that way internally and it's way more trouble than it's worth to do so.
2) This situation already comes up in legacy code. If you want the mob to move north when hitting a wall going northwest, you need to do custom processing for it. That hasn't changed. Changing this as you describe would be inconsistent and would break existing code.
3) A proc like you describe is simple to setup in soft code, but we have discussed the option of adding appropriate step and walk procs.
4) I'm more than happy to modify the Cross() proc, but what values do you suggest providing? The current distance or the potential overlap? Distance in each direction? Direction of movement? (Note the get_dir() is there on purpose because the mob's dir might not be the push direction, if moving diagonally.)
Opacity is ridiculously incompatible with proper pixel movement. It wasn't a consideration.
we've made it our mission to do this in the most intuitive way possible.
var/r = 16 // rod lengthvar/d = dir1 | dir2 // find the diagonalvar/dx=0, dy=0, dw=0, dh=0if(d & (NORTH|SOUTH)) dh += rif(d & (EAST|WEST)) dw += rif(d & WEST) dx -= rif(d & SOUTH) dy -= rvar/list/targets = obounds(src,dx,dy,dw,dh) - obounds(src)
I agree however that a picture would be good. I'd love for the reference to have diagrams. At the moment this is frustrated by IE's lack of support for inline images (except for IE9) but I'd love to know of any good alternatives. We could distribute images with the ref but it complicates things.
The problem I responded to in that post had no intuitive solution. The author wanted something that would give an 8x16 bounds box, or 16x8, depending on the direction, and in some cases would cover a swing from one direction to another (a la 3D Dot Game Heroes). There was really no way to cover a case like this with a simple built-in function.