Anyway, let me get to the point here. I've succeeded in creating my own movement animation, dealing with jerky pixel movement, and overriding the Move() proc so that it calls my personal move proc instead. The final hurdle comes from something that appears to be inherent in the Move() proc itself.
See, when I hold down the movement key, it seems to me that the calls to the move function actually stack up, which means that between 2 and 5 movements actually get stored up and are called AFTER I release the button. This, of course, leads to a "sliding on ice" effect, including to the point where one goes sliding off of the edge of the screen before the new collision system kicks in. Now, I know that this is caused by the animation part of my pixel movement, wherein I make the character "slide" between two positions so as not to look jerky. This involves a sleep call within a proc, which naturally delays the call of the next movement (to prevent the animation from getting choppy).
However, this causes two problems. First, as mentioned, is the slidey movement which is absolutely not what I want. Secondly is a side-effect which causes the walking animation of the icon not to appear while the mob is moving (long story here, just take my word for it).
So my question is this: Is there some way I can get around the stacking up of calls to the Move() proc? Or is there anyway to make the movement of my mob fluid enough without having to do so? Anyway, in case you wanted to see what happens, I've included my code thus far, though you'll need a map and a player icon to really test it out.
#define PIXEL_STEP 8
mob
proc
PixelMove(Dir=0,Pixels=PIXEL_STEP)
// Avoid having this proc called more than once at a time
if(src.moving)
return
// Dir is passed in as the direction of movement. Pixels refers to the number of pixels
// the character is moving. Note, this will round to the nearest factor of 32 to avoid bugging up
if(Pixels < PIXEL_STEP || !Dir)
return
src.moving = 1
src.dir = Dir // Face the correct direction
if(Pixels % PIXEL_STEP != 0)
// This makes sure the player moves in steps of PIXEL_STEP pixels
Pixels = Pixels % PIXEL_STEP
// Now we begin the new pixel-by-pixel movement
var
// These values affect how much we move in a particular direction
newpx = 0
newpy = 0
numofsteps = Pixels/PIXEL_STEP
switch(Dir)
if(NORTH)
newpy += PIXEL_STEP
if(NORTHEAST)
newpy += PIXEL_STEP/2
newpx += PIXEL_STEP/2
if(NORTHWEST)
newpy += PIXEL_STEP/2
newpx -= PIXEL_STEP/2
if(SOUTH)
newpy -= PIXEL_STEP
if(SOUTHEAST)
newpy -= PIXEL_STEP/2
newpx += PIXEL_STEP/2
if(SOUTHWEST)
newpy -= PIXEL_STEP/2
newpx -= PIXEL_STEP/2
if(EAST)
newpx += PIXEL_STEP
if(WEST)
newpx -= PIXEL_STEP
// By now we know which direction we'll be stepping in, let's take the steps
var
xstep
ystep
newx = src.pixel_x + (numofsteps * newpx)
newy = src.pixel_y + (numofsteps * newpy)
// Pixels SHOULD be divisible by 4. If not, you've changed PIXEL_STEP to something funny
xstep = (newx - src.pixel_x)/4
ystep = (newy - src.pixel_y)/4
while(src.pixel_x != newx || src.pixel_y != newy)
src.pixel_x += xstep
src.pixel_y += ystep
while(src.pixel_y >= 16)
src.y = src.y+1
src.pixel_y -= 32
while(src.pixel_y < -16)
src.y = src.y-1
src.pixel_y = 16 + src.pixel_y
while(src.pixel_x >= 16)
src.x = src.x+1
src.pixel_x -= 32
while(src.pixel_x < -16)
src.x = src.x-1
src.pixel_x = 16 + src.pixel_x
src.icon_state = src.savediconstate
src.moving = 0
I would appreciate any assistance people can give. If I can't get this working, I'll have to switch to a different engine for it, which will suck because I know DM pretty well by now and was hoping to be able to continue using it for this game.
http://www.byond.com/members/Xooxer/files/ xo_PixelStep_src.zip