Ok so before you say it, I DID read the other thread. Personally, I have an issue that's not covered in it so I thought I'd ask about it here.

Essentially I've written a system that uses the pixel_x and pixel_y variables of a player to simulate pixel by pixel movement, and I have the algorithm for collisions based on that ready (though not in use yet). My problem, however, is that the player icon itself neither animates nor slides across the pixels as it should and so instead I get a kind of teleport effect where the player instantly appears up a few pixels without sliding there as though moving.

Now while I'm sure I can get the movement animated with the flick() proc, I am kinda stumped about the not sliding thing. I looked at the pixel projectile demo and it does the teleporty movement too, which doesn't help at all.

So anyway, any advice on this? In particular I'm worried about the teleport vs slide thing. It looks really bad...

Eh as a side note, whenever I move the player up a tile they animate from one square to the next walking, which is NOT what I want. Am I doing something wrong? Basically, I'm using the following:
src.loc = locate(src.x,src.y-1,src.z)
If you are doing pixel-based movement you need to turn off animate_movement. If it is left on, you have tile-based movement stuff conflicting when you change the actual tile-based location.

When you have something like the following to update the tile-based location
pixel_y -= 32
loc = get_step(src, NORTH)

since you are actually moving up a tile, the built-in tile movement slides you up, but the pixel_y part jumps you down 32 pixels, and that is what gives you the unwanted effect where you jump down a tile then slide back up.
In response to Loduwijk
That might have something to do with it, I'll check it out. Uh... any idea about the other stuff?
An icon is not supposed to slide fluidly from one location on the screen to the next when you change the pixel location. If pixel_x = 4 and you set pixel_x to 20, it does not slide fluidly from 4 to 20, it is going to just jump 16 pixels over; that's how it works.

If you want it to move in smaller increments you need to make it do that yourself.
var/moving = 0
if(moving) return 0
moving = 1
for(var/index = 1 to 4)
pixel_x += 5
/* at this point, after the loop, you will have
* moved 20 pixels to the right, but it will have been in 5-pixel
* increments a tenth of a second at a time, then you will be
* able to move your character again 0.4 seconds later

Obviously, you don't want to do it exactly like that, but that's the general idea. Also, the above does assume you define your own MoveRight() for atom/movable, though again, you don't want to have a function for each direction, and I was just demonstrating the general idea.
In response to Loduwijk
Yeah, that's basically what I had been using. Now, movement animation aside, I have a different issue. My code is as follows (It's like that because I want to handle some more complex procedures):

// 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
// This is used to loop around, calling the movement proc until either the final place of stepping is reached, or
// the character bumps into something
bumped = 0
newx = src.pixel_x + (numofsteps * newpx)
newy = src.pixel_y + (numofsteps * newpy)

// To make movement appear smooth, we want to break it up into even sections.
// First we need to see just how far they move. After all, if they run into something
// mid step, we'll need to accomodate for that. (I skipped this step)

// Collision code goes here

// 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 >= 32)
world << "Py: [src.pixel_y]"
src.pixel_y -= 32
src.loc = get_step(src,NORTH)
while(src.pixel_y < 0)
world << "Py: [src.pixel_y]"
src.loc = get_step(src,SOUTH)
src.pixel_y = 32 + src.pixel_y
while(src.pixel_x >= 32)
world << "Px: [src.pixel_x]"
src.pixel_x -= 32
src.loc = get_step(src,EAST)
while(src.pixel_x < 0)
world << "Px: [src.pixel_x]"
src.loc = get_step(src,WEST)
src.pixel_x = 32 + src.pixel_x

src.moving = 0

And while it works more or less, after about 5 steps up it won't let me go up any further and instead the mob repeatedly steps on the same tile over and over and over, which is thoroughly annoying and I can't figure out what might be the cause.

EDIT: ARGH! Never mind, It turns out the game was playing with me because I had a large map, and it was actually just the client's eye moving. Since my map was all the same tile, it appeared as though I was flicking back to the same tile, though I was really moving up at the same time as the camera -_-

EDIT AGAIN: Ok, new issue. When I hold down a direction key, the mob will move a few extra steps once I relese the key. I do NOT want this, as it's the equivalent of running across ice and since the terrain isn't ice it can get frustrating. any ideas as to WHY it's happening?
Perpetr8r the Perpetu8r wrote:
EDIT AGAIN: Ok, new issue. When I hold down a direction key, the mob will move a few extra steps once I relese the key. I do NOT want this, as it's the equivalent of running across ice and since the terrain isn't ice it can get frustrating. any ideas as to WHY it's happening?

I don't see any place that takes timing into consideration for the multiple pixel shifts for a single movement. It appears as though each movement should result in four separate pixel-jumps the way you have it, but it all takes place near instantly such that, to the end user, it should look like a single large jump instead of four smaller ones.

And once the movement begins, that function will likely be finishing and returning before any more movement commands in the queue are processed, meaning the "if(moving)return;moving=1" part doesn't have a large impact on anything.

Long story short: you have no movement delay. That could be part of the problem.
wat the heck