Move by pixel increments in Feature Requests

ID:118600
 
Sep 15 2011, 3:36 pm (Edited on Sep 15 2011, 5:01 pm)
Redundant
Applies to:DM Language
Status: Redundant
This feature has already been implemented, or is already achievable with existing methods.
As outlined on the forum it is not possible to call use Move() to move a movable atom without knowing what turf is the destination of the movement. This doesn't make sense in games using non-atomic movement. If all that a developer want to do is move the object by an arbitrary number of pixels, it is not known whether or not this will result in the object crossing into a new tile.

I suggest that when step_x or step_y are supplied to Move(), that NewLoc should be treated as an optional argument:

Move(Dir=some_dir, step_x=3)

Alternately, there should be a proc that can be used like Move(), but without specifying a new location.

Note: The step() and walk() procs are insufficient. They cannot be called without changing the mob's direction to that of the movement. This is only possible with Move().

Edit: Also, step cannot replicate all the behavior of Move(). In Move, it is possible to specify different values for step_x and step_y. Using step() or walk(), you can only move at 45 degree angles.
#1 Sep 15 2011, 5:15 pm
Yeah this would be some pretty useful functionality.

In my platformer from the impromptu ZYNCKO contest, I call step() twice: once for each component of velocity along world axes. There also seems to be a bizarre problem with calling step() on a decimal that's less than 1. I'm guessing it floors the input. This causes a whole plethora of problems when you've implemented air resistance.
#2 Sep 15 2011, 5:20 pm
I call step() twice: once for each component of velocity along world axes.

This is what I've ended up doing as well. Some people may not think through what exactly is going to happen in this case, and call the problem solved. I'd like to point out that this is not a good solution, because, depending which axis you call step() on first, diagonally moving projectiles may hit atoms above/below them, or to the left/right, when they shouldn't have hit anything at all.
#3 Sep 16 2011, 1:04 pm
To move by a pixel offset dx and dy, you do this:

Move(loc, 0, step_x+dx, step_x+dy)

I realize that may not be 100% intuitive so the simple option is just to create a soft-coded proc to do it, which could also have the advantage of setting the direction for you.

atom/movable/proc/PixelMove(dx, dy)
    var/d = 0
    if(dx) d |= (dx>0) ? EAST : WEST
    if(dy) d |= (dy>0) ? NORTH : SOUTH
    if(abs(dx) >= abs(dy)*2) d &= 3
    else if(abs(dy) >= abs(dx)*2) d &= 12
    Move(loc, d, step_x+dx, step_y+dy)