Ok so as you may or may not know, I posted earlier about pixel-by-pixel movement with BYOND. Having played around with it for a while, I'm beginning to see a trend of "You're not supposed to mess with this" going on here, as it seems BYOND has some low level processes that I can't actually access which are causing my fledgling system to fail.

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

// Avoid having this proc called more than once at a time
// 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)
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
// These values affect how much we move in a particular direction
newpx = 0
newpy = 0
numofsteps = Pixels/PIXEL_STEP
newpy += PIXEL_STEP
newpy += PIXEL_STEP/2
newpx += PIXEL_STEP/2
newpy += PIXEL_STEP/2
newpx -= PIXEL_STEP/2
newpy -= PIXEL_STEP
newpy -= PIXEL_STEP/2
newpx += PIXEL_STEP/2
newpy -= PIXEL_STEP/2
newpx -= PIXEL_STEP/2
newpx += PIXEL_STEP
newpx -= PIXEL_STEP

// By now we know which direction we'll be stepping in, let's take the steps
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.
I have an old pixel step library I made some time ago. I just recently added in client eye pixel movement, so now it behaves like pretty much every normal sprite-based console game. Take a look, it might be useful.
In response to Xooxer
Um... there seems to be a problem with it. I get a lot of compilation errors about client.pixel_x not existing, which is true as far as I know. Is that supposed to be src.pixel_x perchance? Or did you define a pixel_x for clients and not include it? I'm confused.
This is from the version announcement topic in the Announcements section.

Tom wrote:
By popular request, there are now client.pixel_x and client.pixel_y vars, for pixel-level adjustments to the player's view. Example code follows:
// 1-second shake
for(var/i=1, i<=10, ++i)
client.pixel_x = rand(-8, 8)
client.pixel_y = rand(-8, 8)

This was added in version 413.978. Make sure you have the latest BYOND.
In response to Kaioken
Ugh... I swear I updated for like the 8th time just a short while ago. *downloads new version AGAIN*