not only in ISOMETRIC, but every other map_format aswell... It's a known issue for a long time iirc.

Looking at the demo, I see jank but I think there are several causes here.

The main cause of jank appears to be because the movement is just the default dir+REP macros. If I replace them with a movement loop and Any/Any+UP macros, that particular source of jank vanishes.

After that, there does still appear to be a smidge of stutter, and I think I see why. As the mob picks up pixel offsets from the gliding (since gliding is used to interpolate when world.fps and client.fps differ), those odd offsets may be a pixel off in one direction or another due to the way they get translated into isometric. E.g., a step_x of 8 translates to 4 pixels to the right and 2 pixels down, which is easy because 8 divides evenly by 4, but a step_x of 7 or 9 has to round off and invariably a rounding error will be introduced. I think this is why you're seeing a different result in isometric vs. topdown.

I'm curious if this is a fault of 513 specifically and how glides are now tied to elapsed time instead of total ticks. Your chosen client.fps of 60 was going to have an issue no matter what, but in 512's old way of handling things, a client.fps of 40 which is 2x your world.fps would see the step offsets changing by 8 and would have given pleasing results.

However, I did try looking at topdown mode for comparison and even there, I'm still seeing a little bit of jank on occasion; it only occurs when world.fps and client.fps don't match. This is with a movement loop in place. My theory about this is that there are probably some sync issues where the client simply gets out of step with the server's timer, which of course is exacerbated by the 60 fps choice but even a choice like 40 or 100 still shows the issue. I'll have to look at the gliding code in much more depth to figure out why this is happening.