ID:1838041
 
Or have all of the walk procs become terribly inefficient and basically unusable?

I'm too lazy to upload a file, but I've been testing it.
The test is simple, all I do is create x amount of objects, then have them call one of the walk procs. I tried it at a variety of fps and step_size is always 2.
Here are the results on my processor (i5 2500k), I'm also using the most recent stable version of BYOND (506.1250).

10 FPS
100 objs using walk (south): 15-16 CPU
100 objs using walk_rand: 2-12 CPU
100 objs using walk_towards: 27-29 CPU
100 objs using walk_to: 85-90 CPU

30 FPS
100 objs using walk (south): 47 CPU
100 objs using walk_rand: 6-36 CPU
100 objs using walk_towards: 86-90 CPU
100 objs using walk_to: ??? CPU (basically resulted in a freeze, saw a spike of 250 CPU usage once)

60 FPS
100 objs using walk (south): 95-96 CPU
100 objs using walk_rand: 12-48 CPU
100 objs using walk_towards: ??? CPU (freeze, saw 180 CPU before it froze)
100 objs using walk_to: ??? CPU (freeze so bad I couldn't see sort of reading)


Now, I understand walk_to has path finding, and should be used sparingly. But you're going to have to explain the others to me. They're essentially just movement in a straight line. Is there any reason for such intensive CPU usage just from movement?

I know you're going to say having 100 moving objects is overkill, you should never do it, you should disable them when they're not used and what not. But for your average RPG which averages like 5-10 players (which isn't a lot), 100 things moving really isn't a lot.

So, can anyone explain to me what exactly happened to the walk procs since I last used them (which admittedly was years ago)? I remember being able to have a thousand things moving around without any issue on a weaker computer, now I can barely manage 10% of that unless I use some horrid FPS that wouldn't have been acceptable back in 1985.
I'd be willing to bet if you upped the step_size to 32, or 16, or hell maybe even 8 then the CPU would go down a lot. I think I remember noticing it a while back, and wondering about it. Those actual figures are pretty shocking either way though.

I'm also curious about whether making a custom walking function that just simply does step(src,dir) in a while() loop would yield the same results. Technically speaking it probably should, but does it? I might fiddle with it later to find out.

Definitely a good question, and an interesting thread either way.
In response to Toddab503
Just tested using different step sizes. Results are more or less the same.

The only way I can get walk to use less cpu is by changing the lag between each step. Problem with this is movement stops being smooth and just looks clunky as hell (like the object is moving at very low fps compared to everything else).
The walk_to results I understand, since there's pathfinding involved, but the other ones really shouldn't be that high unless the FPS is also ridiculously high. Regular walk() should just be calling step().
In response to The Magic Man
Huh. Now that is really puzzling behavior. Pixel movement being on or off would probably effect it a bit, but that's not important. I cannot understand it being so high with or without it.

I think I might run a few tests as well, but to do that I need to know a little more. How far are you having the walk procs move the objects in your test? I'm guessing to the edge of the map, although if so I'd need to know map size, and also I'd assume you'd have something set to clear them at map edge because otherwise I think they continue to act as though they're moving when they're not.

That could jack up the CPU too, I imagine. It's essentially infinite movement, but I doubt you've done that. I theorize that it would do that because I know whenever I have an object hit a dense turf without handling for it, but I have the object set to clear after X amount of moves the count still carries up and clears the object.
After playing around with it more I've figured out what the issue is.

If lots of objects occupy the same place and they're all walking, CPU usage increases massively. If I place hundreds of objects at random locations there is no issue with CPU usage, if I place them all at the same location, then it jumps up massively.

I suspect it's something related to handling collisions (though all of these objects are not dense, nor is there any thing happening with bump/cross/crossed).
Yes, that would make sense. Pixel movement grabs a list of all the objects it might encounter entering or leaving, and I think some of that comes into play even in tile movement. I'll see if I can streamline that.

At your convenience, please move this to Bug Reports and fill in the bug report info. (Might want to edit the subject line too.) I definitely consider the slowdown an issue.