ID:136011
 
I'm working on a sidescrolling game that uses multi-tile mobs with pixel movement; as such, animate_movement is turned off for everything. Moreover, each player does have an independent client.eye which is tracked seperately from the main mob. One of the problems of pixel movement is that it's not compatabile with client.eye; eh, I can live with that. But I'm noticing kind of an odd phenomenon; when a mob "crosses over" into the next turf and their pixel_x wraps around from positive to negative, their client.eye is supposed to move to the next turf over too. Instead of snapping to the next turf, however, their view ends up moving about 8 pixels over at this point, and then catching up as soon as they move again. Any idea what's going on?
To be a bit more concise, the issue here seems to be that setting a mob's pixel_x/y at the same time as setting its client's eye's location seems to cause the view to get stuck with a pixel offset instead of a whole-tile-multiple.
In response to Leftley (#1)
To be a bit more concise, the issue here seems to be that setting a mob's pixel_x/y at the same time as setting its client's eye's location seems to cause the view to get stuck with a pixel offset instead of a whole-tile-multiple.

The same as the mobs offset :P? If it does that oculd be useful.
In response to Theodis (#2)
Theodis wrote:
To be a bit more concise, the issue here seems to be that setting a mob's pixel_x/y at the same time as setting its client's eye's location seems to cause the view to get stuck with a pixel offset instead of a whole-tile-multiple.

The same as the mobs offset :P? If it does that oculd be useful.

I don't think it's quite the same, but it's somewhere in that ballpark. Unfortunately I haven't been able to come up with a way of getting this effect without massively jerking the view screen around; my concise version was a little bit over-simplified. It doesn't occur unless there's a visible change in client.eye.loc; moving it and then putting it back in the same tick doesn't do anything, nor does moving its z level. You might be able to work something out using offsets > 32 (or < -32) to see if you could get the eye's faux pixel offset to offset a floating eye that moves back and forth relative to the player with each movement, but this would be very complex for any object with a physical map presence, and would lead to display problems with other players around the edges of the screen.