Pixel Movement in Feature Requests

Page: 1 2 3 ... 6 7 8 9 10
#140 Jun 26 2011, 12:28 pm (Edited on Jun 26 2011, 2:14 pm)
I think I've made an optimization of my own to pixelmovement. a big cause of the lag was can_bump() having to check 8 atoms (or more) at a time, 40 times per second.

I've added a line to check velocities, if a atom has zero velocity, don't bother checking if it moves. This cut the static CPU rate to 0. Before, the cpu would spike from 7-14 for each player on the server, now it only counts if they're moving. As for can bump, you can exclude any atoms you're moving away from, so if you have a positive vel_y then you don't check the atoms to the south, southeast, or southwest. This cuts checking 9 turfs and their contents to checking 6 instead. I don't have results for this yet but I thought I'd say something about t in the meantime.

As for any replies to things I've said in the last post: I'm not very good in explaining some ideas that I have but if I had the time to visually explain it you'd see what I mean. I'm terrible with the written word. (or typed in this case)

Edit: can_bump() calls 15-30 times per tick even though it's only checking 9 turfs, it seems to contribute to the issue.
#141 Jun 26 2011, 2:31 pm
Bravo1 wrote:
I think I've made an optimization of my own to pixelmovement. a big cause of the lag was can_bump() having to check 8 atoms (or more) at a time, 40 times per second.

Last time I checked, most of the CPU time was spent in set_flags(). can_bump gets called a lot, but the processing to compute a result is usually trivial. Here's the default can_bump proc:

if(isturf(a))
    return 1

if(isobj(a))
    return a.density

return 0


You'd have to call that thousands of times before the CPU time adds up to anything significant. Inlining this behavior in pixel_move would help, but because this isn't the bottleneck you're never going to see a huge performance gain from this.

As for can bump, you can exclude any atoms you're moving away from, so if you have a positive vel_y then you don't check the atoms to the south, southeast, or southwest. This cuts checking 9 turfs and their contents to checking 6 instead.

That's a reasonable change, but if the call to can_bump is very fast you might take more CPU time determining that you don't need to call can_bump. It's hard to beat "if(isturf(a)) return 1" :-)

Assuming it's still the case that most of the CPU time is spent in set_flags (for idle mobs at least, moving mobs may spend more time in pixel_move, but that's unavoidable), you'll see a bigger benefit by optimizing how/when it's called (which is one of the tips in How to Optimize a Pixel Movement Enabled Game). If you're not reading the mob's on_left, on_right, etc. vars anywhere, you might not need to call set_flags at all (for projectiles it's often not necessary).

I've added a line to check velocities, if a atom has zero velocity, don't bother checking if it moves.

This is already done in pixel_move(). The first line inside the loop is:

if(dpx == 0 && dpy == 0 && dpz == 0) break


However, the call to pixel_move is only part of the movement loop. Things like gravity(), move(), action(), and set_flags() are still being called if the mob isn't moving (which is often necessary, because the environment can change in such a way that those calls are necessary).
#142 Jun 26 2011, 2:46 pm
When you get down to it, one of the largest reasons why we want native pixel movement is to allow us to make games using pixel movement that are cpu-efficient... however since we can already create our own pixel movement systems, why not focus more on fixing the things that cause BYOND to slow them down in the first place? If we were to have that fast native pixel movement we all dream of, improvements would have to be made to the engine regardless..

I'm all for native pixel movement, though. It's a no-brainer that the engine needs it badly, but even though I can't name what would fix it myself I think there are other things that could be focused on to improve the overall speed of how BYOND handles it.
#143 Jun 26 2011, 3:07 pm
The only way to make it efficient is to have movement handled on the client. As long as the server handles everyone's movement (and as long as you have to reduce world.tick_lag to make it smooth) there's no way to make it as efficient as people wish it could be (whether it's native or not).

It sounds like there are some internal things holding BYOND back when it comes to things like this, but its hard to tell. While I was making my library, I tried to think "what new built-in procs would make this easier?", but I couldn't come up with anything. There just seems to be some general slowness in how certain things are handled. There's no reason why dreamseeker should struggle to run at 30 fps. If these things were improved, it would help everything, not just user-made pixel movement.
#144 Jun 26 2011, 3:11 pm
Forum_account wrote:
The only way to make it efficient is to have movement handled on the client. As long as the server handles everyone's movement (and as long as you have to reduce world.tick_lag to make it smooth) there's no way to make it as efficient as people wish it could be (whether it's native or not).
It sounds like there are some internal things holding BYOND back when it comes to things like this, but its hard to tell. While I was making my library, I tried to think "what new built-in procs would make this easier?", but I couldn't come up with anything. There just seems to be some general slowness in how certain things are handled. There's no reason why dreamseeker should struggle to run at 30 fps. If these things were improved, it would help everything, not just user-made pixel movement.

That's what I thought. Is multiprocessing a thought o_o
#145 Jun 26 2011, 3:21 pm (Edited on Jun 26 2011, 4:13 pm)
Forum_account wrote:
The only way to make it efficient is to have movement handled on the client.
Open client sided processing would cause so many other problems, complicate the language, and offer so few benefits that its hardly a feasible solution, especially for this specific feature. In vast majority of cases, it would actually offer far worse "performance" due to the networking requirements alone.

Honestly, if they were willing to take just a few simple steps, we could probably build our own competent pixel movement systems, but since they aren't, we might as well just get them to do everything (its probably never going to happen one way or the other) - not to mention the countless benefits that a built-in implementation would provide.

As for performance/ticks, maybe they could just remove that processing limit to begin with. Instead of sitting around for 99% of an unused tick, that time could be spent processing the next one - that is how most (if not all?) actual games work, and if I'm not mistaken, BYOND's internal processing works that way as well.
#146 Jun 26 2011, 3:43 pm
This is already done in pixel_move(). The first line inside the loop is:

if(dpx == 0 && dpy == 0 && dpz == 0) break

Sorry, it's nearby()that bring sup the issues.

After checking it, it seems that the break you have here does save a bit of time but nearby() and the bumping checks are still called since the break check happens after everything is said and done. To skip this, I added a similar check to movement just before pixel_move() which cancels any bumping checks entirely if you're not moving.

It cut down the cpu jumping from 0-14 (at any time) to 0 (while not moving).

As for nearby() it's practically the same, except it does if() checks for vel_x and vel_y. Total of 4 if()'s seems to take only nanoseconds longer but can result in using 3 less turfs (and their contents)for the check, which saves more time than it uses. It's only a noticeable change with multiple mobs.
#147 Jun 26 2011, 4:16 pm
I could add a similar check before the for loop in pixel_move to avoid the call to nearby. The problem with not checking some tiles because you aren't exactly moving towards them is that those tiles may contain atoms that you would bump into. The CPU cost is from the call to nearby and the cost of it returning a list (it makes a lot of lists for the garbage collector to clean up). Whether the list has 6 or 9 items won't make a difference - especially when the loop is exited on the first iteration.
#148 Jun 26 2011, 4:22 pm
Also, Forum_Account's pixel_movement is competent, but due to byond being as slow as it is, p_m is hampered and slow. For single-player games it works fine and dandy but multiplayer is damn near impossible with it due to how much the server has to handle all at once.

If client side operations were to be done with pixel_movement, the clients would do the calculations and the server would apply the move after making a check of its own to make sure the numbers it's getting aren't going to make you fly around a server.

Then again, this sometimes happens already when a game gets overloaded with players, it's to be expected.

Don't get me wrong, I don't think it's a quick/easy/efficient fix, but it'd be a start.

All of this arguing over whether or not things should be done is what's killing the progress, because no one seems to be settling on an idea so that we can actually progress.

We wouldn't ask for this feature if it wasn't necessary. We have a good pixel movement system that is, even now, still getting better, but it's only getting better because of how much byonds internal code holds it back.

on Library usage:
Libraries are nice, they help you do something without having to do all the work yourself, but don't take it as if we give up on doing any work at all. Libraries are tools to be used, but not exploited. pixel_movement is a great example, I could have made something much like pixel_movement , but instead of wasting my time on it, I picked it up and changed it to meet my needs.

Consider this: If you buy a car and then soup it up with a new engine, new intake, exhaust, a turbo, etc. Am I any less of a mechanic because I didn't build the car from scratch? Hell no, why build a car from scratch if you have a perfectly fine framework sitting there for you to use freely?

I do dislike when people buy a car, put new rims on it and say "I built that", but there is varying degrees of this labeling a modification a ripoff just because it still resembles the original is a little over-the-top and presumptuous.

Back to "make a competent library instead of asking them to add in pixel movement":
Another car analogy, sorry but it fits: Let's say I build a turbo for a car and install it. The car now runs fantastic from 0-60 but can't go any faster because the turbo would pull in WAY too much air. Saying the turbo is crappy is never a reasonable response. The engine has it's limits and should be modified to broaden those limits to allow the turbo to do its job.

in this case we're not asking to modify the engine to fit the turbo, we're asking to build the turbo into the engine on standard. We can modify the engine to better support the turbo but ultimately it'll be better off with one that's built in because it will be designed specifically with THIS engine in mind, not just any other engine.

Sorry if it doesn't make sense I'll give you some help:

tl;dr The best solution to this argument is to add pixel based movement in. Yes, there are other ways to add support for the library, but ultimately it's going to run a lot better if it's hard-coded as soft-coded systems will always be at a disadvantage.
#149 Jun 26 2011, 4:40 pm
Bravo1 wrote:
For single-player games it works fine and dandy but multiplayer is damn near impossible with it due to how much the server has to handle all at once.

A Miner Adventure runs just fine. It even has dynamic lighting and flowing water, which account for more of the CPU and bandwidth usage than the pixel movement.

The best solution to this argument is to add pixel based movement in. Yes, there are other ways to add support for the library, but ultimately it's going to run a lot better if it's hard-coded as soft-coded systems will always be at a disadvantage.

Any game would run better if it was written from scratch instead of using DM, so it's hard to justify that a feature would be better implemented in DM than as part of BYOND itself. Still, there are two points worth considering:

1. Is it worth the BYOND staff's time? There are some features we can't make ourselves in DM. Why should the staff spend their time working on a feature we can already make?

2. How useful will the native feature be? Making it built-in might make it faster but can limit its flexibility. Look at how opacity works - because it's all built-in there's no way to customize the visibility calculations. If you want them to work differently, you're out of luck. Would a pixel movement implementation turn out the same way?
#150 Jun 26 2011, 4:45 pm
1. Yes it's worth the time. Tile based movement is an archaic at best.

2. It'd be incredibly useful, over a third of the new games coming out are using pixel movement that could be a higher number if we had a much smoother system.

As for speed issues with a miner adventure, Isometric maps seem to have a lot of trouble with pixel_movement.
#151 Jun 27 2011, 6:32 am (Edited on Jun 27 2011, 6:38 am)
Bravo1 wrote:
1. Yes it's worth the time. Tile based movement is an archaic at best.

I agree that the feature is a good one, but the question is: would it be the best use of the staff's time to implement this? The best case is that they spend several months to add a feature that many people have already implemented themselves. Why bother? In that time, they could instead add features that would be much more difficult (and sometimes impossible) for people to add themselves.

2. It'd be incredibly useful, over a third of the new games coming out are using pixel movement that could be a higher number if we had a much smoother system.

I don't think speed is what's stopping two thirds of BYOND users from using pixel movement. There are many BYOND games that use pixel movement, so its very hard to make the argument that user-developed methods cannot be sufficient - there's already proof that they are. The problem I was getting at with this question is something I've brought up before:

If the feature is built-in and flexible you get very little performance benefits because developers will have to override many of the procs to make the system work how they need it to work. The server is still executing DM code, so this won't be any faster than a completely user-made implementation could be. If the feature is not flexible you can get better performance, but you'll have to make a BYOND feature request every time you want the pixel movement to behave a little bit differently (imagine if you couldn't override Move or Entered and had to make BYOND feature requests instead, sounds like fun, right?).

Some features are better implemented in DM than added natively as part of DM, this is one of those features. It's the reason why BYOND doesn't come with an Attack() verb - there are many ways you'd want it to work, so you just have to make it yourself (that's why we have the DM language). We can probably find some features that the BYOND staff could implement to improve the performance of user-made pixel movement systems, but that's not what is being asked for (or discussed) here.

As for speed issues with a miner adventure, Isometric maps seem to have a lot of trouble with pixel_movement.

I'm not sure what you're getting at there. Can you elaborate?
#152 Jun 27 2011, 6:41 am (Edited on Jun 27 2011, 6:53 am)
Forum_account needs to be banned from posting in this topic. He has done nothing but constantly attempt to shut down this request by making the same idiotic points. Points which countless people have already smacked down numerous times.
The only reason he is even against this request to begin with is because he has already made a sub-par pixel movement library of his own, and doesn't want a competent replacement system being released. "THERE WON'T BE A BUILT-IN PERFORMANCE INCREASE, IT WON'T BE FLEXIBLE, MY PIXEL MOVEMENT LIBRARY IS THE BEST THING EVER MADE BY ANYONE ANYWHERE EVER, THIS FEATURE REQUEST IS TERRIBLE". Yea, we've heard your objection to improving the engine. If you want to keep spamming this topic, then at least come up with some legitimate/new counter points.
And now half of his conversation has degraded into a discussion with Bravo about how the coding in his library is terrible, and needs basic improvements to be feasible even when idle.

Its been over 2 months since this was requested, if they had started working on it day one, instead of listening to various idiots pointlessly argue against such a blatant improvement, it would probably be finished by now.
#153 Jun 27 2011, 6:49 am
Well, I've had to scrap pixel movement in an isometric game before due to speed issues, then again that game was meant to be multiplayer.

It seems that with more than 5-6 players at a time, he game will start to slow down or have adverse effects to the controls.

One such effect was that, when removing your finger from a movement key your mob would stop, walk again for a fraction of a second and then stop again. It caused some really bad effects to the combat system and ultimately it had to be removed and replaced with an adaptive version of the tile based movement.

Something about the way isometric maps are processed visually makes them more taxing on the cpu for each tick. I've noticed I can load images on every turf for a lighting system and have it work completely fine in a 2d map, but isometric maps will have noticeable slowdowns, unless you're standing near the edges of the map. Perhaps it's because of the sheer number of visible tiles with isometric maps, I'm not sure.


Either way, if you wanted to have a game with more than 20 players, even if it's tile based, pixel movement would slow things down way too much to be playable.

I ran several tests with just pixel movement working with my game Darkness. Once there was 15+ mobs on the map the game would slow down considerably, being completely unplayable after 30+ mobs.

Most multiplayer games out there easily support over 50 players on a server at once and it doesn't seem like pixel movement will ever be able to handle that unless you're sitting on a 6ghz single core cpu, of which I don't think there are many within a feasible price range for developers.

As for making it flexible and fast, it's all up to how they want to implement it. There are ways to get both but it sounds like the biggest argument against pixel based movement is: "It's too much work" when, honestly, it'd be one of the most beneficial things byond has ever implemented.
#154 Jun 27 2011, 6:50 am
Also F_A's pixel movement isn't sub-par, it's fantastic, but due to the limitations of the engine supporting it, it's slow on large scale games.
#155 Jun 27 2011, 7:15 am (Edited on Jun 27 2011, 10:24 am)
Bravo1 wrote:
Perhaps it's because of the sheer number of visible tiles with isometric maps, I'm not sure.

That would be my guess. The same problem would happen in top-down games, it just took a lot more objects or a larger view to get it to happen. There was a BYOND bug that caused controls to be unresponsive when the client couldn't keep up with drawing the screen, but that should have been fixed (several updates ago).

Most multiplayer games out there easily support over 50 players on a server at once and it doesn't seem like pixel movement will ever be able to handle that

1. Increasing the framerate will lower how many players you can support. Whether pixel movement is built-in or not you'll have to increase the framerate (try playing Darkness at 10 fps and see how choppy it is :-D), so a more limited player count is something you'll have to deal with no matter what.

2. My library could use a bit of optimizing. It hasn't been a big concern to me, but I've been looking into it more lately. I also suspect there are many issues with BYOND that'll only be uncovered and fixed as more games use higher framerates (ex: the issue with unresponsive input mentioned above).

Also F_A's pixel movement isn't sub-par, it's fantastic, but due to the limitations of the engine supporting it, it's slow on large scale games.

Thanks! If you have some examples of things that performed more poorly than you expected, I'd be curious to see what you were doing - either to find a soft-code optimization or see if something in the library itself should change to improve performance.

As for making it flexible and fast, it's all up to how they want to implement it. There are ways to get both...

That's the problem, finding a way to get both. So far, nobody has explained how that would work. The current, tile-based movement system is fast because it's simple, not because it's built-in. People assume there would be an automatic performance gain by making it built-in but its not that easy.
#156 Jun 28 2011, 12:58 am
Bravo1 contributed,

"Also, Forum_Account's pixel_movement is competent, but due to byond being as slow as it is, p_m is hampered and slow. For single-player games it works fine and dandy but multiplayer is damn near impossible with it due to how much the server has to handle all at once.

If client side operations were to be done with pixel_movement, the clients would do the calculations and the server would apply the move after making a check of its own to make sure the numbers it's getting aren't going to make you fly around a server.

Then again, this sometimes happens already when a game gets overloaded with players, it's to be expected.

Don't get me wrong, I don't think it's a quick/easy/efficient fix, but it'd be a start.

All of this arguing over whether or not things should be done is what's killing the progress, because no one seems to be settling on an idea so that we can actually progress.

We wouldn't ask for this feature if it wasn't necessary. We have a good pixel movement system that is, even now, still getting better, but it's only getting better because of how much byonds internal code holds it back.

on Library usage:
Libraries are nice, they help you do something without having to do all the work yourself, but don't take it as if we give up on doing any work at all. Libraries are tools to be used, but not exploited. pixel_movement is a great example, I could have made something much like pixel_movement , but instead of wasting my time on it, I picked it up and changed it to meet my needs.

Consider this: If you buy a car and then soup it up with a new engine, new intake, exhaust, a turbo, etc. Am I any less of a mechanic because I didn't build the car from scratch? Hell no, why build a car from scratch if you have a perfectly fine framework sitting there for you to use freely?

I do dislike when people buy a car, put new rims on it and say "I built that", but there is varying degrees of this labeling a modification a ripoff just because it still resembles the original is a little over-the-top and presumptuous.

Back to "make a competent library instead of asking them to add in pixel movement":
Another car analogy, sorry but it fits: Let's say I build a turbo for a car and install it. The car now runs fantastic from 0-60 but can't go any faster because the turbo would pull in WAY too much air. Saying the turbo is crappy is never a reasonable response. The engine has it's limits and should be modified to broaden those limits to allow the turbo to do its job.

in this case we're not asking to modify the engine to fit the turbo, we're asking to build the turbo into the engine on standard. We can modify the engine to better support the turbo but ultimately it'll be better off with one that's built in because it will be designed specifically with THIS engine in mind, not just any other engine.

Sorry if it doesn't make sense I'll give you some help:

tl;dr The best solution to this argument is to add pixel based movement in. Yes, there are other ways to add support for the library, but ultimately it's going to run a lot better if it's hard-coded as soft-coded systems will always be at a disadvantage."


Koil replied with,

"I believe Gooseheaded's game uses FA's pixel movement library and it's multiplayer and runs just fine.

The feature isn't necessary. The BYOND suite is capable of making excellent games without the need of pixel movement. The problem is the lack of projects actually being developed, which isn't going to suddenly decrease if we have access to built-in pixel movement."

#157 Jun 28 2011, 1:51 pm
Koil wrote:
Bravo1: tl;dr The best solution to this argument is to add pixel based movement in. Yes, there are other ways to add support for the library, but ultimately it's going to run a lot better if it's hard-coded as soft-coded systems will always be at a disadvantage."
Koil: "I believe Gooseheaded's game uses FA's pixel movement library and it's multiplayer and runs just fine. The feature isn't necessary. The BYOND suite is capable of making excellent games without the need of pixel movement. The problem is the lack of projects actually being developed, which isn't going to suddenly decrease if we have access to built-in pixel movement."

I somewhat agree with Koil. At the same time I was hosting using ATP host and CPU was increasing as time went on. The game played fine with 4 players but still reached around 15% CPU usage at one point. The system would be better built in so that CPU could be used somewhere else besides movement. And were not saying that the number of projects would suddenly increase but the quality of the projects certainly would.
#158 Jun 28 2011, 2:33 pm
I'm referring to games with 20+ players, which I've said before but people seem to continue to disregard.
#159 Jun 28 2011, 6:50 pm (Edited on Jun 28 2011, 7:37 pm)
Whether we're talking about a user-made feature or a built-in feature, people have unrealistic expectations of what is possible. Consider how much time you're giving the server to do things. If you want the game to run at 40 fps with 30% CPU usage when 20 players are connected:

40 fps = 1000 ms / 40 ticks = 25 ms per tick
30% of 25 ms = 7.5 ms

Each tick you have to do all of the processing in 7.5 milliseconds. With 20 players you'll have at least 20 mobs. If you figure there are 2 enemies (moving ones, at least) per player and one projectile (on average) per player, that's 80 total mobs.

7.5 ms / 80 = 0.09375 ms = 93.75 microseconds per mob.

Let's think about what you can do in 93 microseconds. Here's a simple proc:

proc/test_proc()
    var/list/l = list()
    for(var/obj/door/d in oview(2,src))
        l += d
    
    var/obj/door/d = pick(l)
    return d


I ran it many times with 3 instances of /obj/door being in oview(2) and it averaged 22 microseconds per call. It's a little bit contrived so this proc is obviously not that useful - the point is to show the amount of processing you can get done in 22 microseconds (check a 5x5 region for objects, add three to a list, then randomly pick one). If this is what you can accomplish in 22 microseconds, it'll be hard to get anything meaningful done in ~94 microseconds. When you consider what would need to be done to check for collisions and handle each mob's AI (or whatever else is being done each tick), 94 microseconds isn't a lot of time. People assume that things will be super-fast because they're built-in, but:

1. That's just not true. If all code written in c++ was fast and the .dmb interpreter was written in c++, DM code would be fast too. I wish it was that easy :-)

2. Even if the feature is built-in it'll be calling procs like Enter, Entered, Move, etc. and these'll take up some amount of time. Not much time, but we're talking about microseconds here. The performance gain won't be tremendous (maybe double).

Assumptions that were made:

1. 40 fps. That's a little high, but you'd want the framerate to be at least 25-30.

2. 30% CPU usage. For a crowded server that's a little low, but it depends on how high the spikes will be. If the CPU usage isn't very spiky you wouldn't have a problem sustaining 50-70% CPU usage. If players have some complex abilities that spawn lots of objects, the spikes could be high and you might want to keep the general CPU usage lower.

3. 20 players connected. I consider that high, but some people consider it low (not every game is an "MMO-")

4. 2 enemies and 1 projectile per player mob. This sounds low but it depends on the game. When you figure that 20 players is a little high it all evens out.

If you do the math again for 30 fps and 50% CPU usage, you get 208 microseconds per mob. This is certainly doable. The first example (30% usage for 40 fps) is possible too (even with a user-made DM implementation), but you probably won't get much better than that. Staying with the assumption of four moving mobs per player, we're still talking about player limits in the 30-40 range.

The biggest ways to improve this:

1. Multi-threading and support for multi-core CPUs. There's some overhead required for coordination, so using a 4 core CPU won't improve performance by 4x, but it'll help tremendously.

2. Offload processing to the client. If every client is responsible for calculating the player's movements and some visual effects, this client-server model becomes a lot more scalable.

The first option is probably the best way to go. Generally, speed problems like this can be solved by waiting for better hardware, but better hardware comes in the form of multi-core CPUs. I have no idea how feasible it is, but it makes a lot more sense than built-in support for pixel movement (the built-in feature will still be slow because it's not effectively using the CPU - it'll be a one-time minor improvement to one aspect of BYOND).

tl;dr Having games run at 10 fps has spoiled you! No matter what we're talking about (pixel movement, AI, pathing, attacks, special effects, etc.), you'll find that you can get away with a lot when the game runs at 10 fps. When you want the game to run at a decent framerate, performance becomes more and more of an issue.
Page: 1 2 3 ... 6 7 8 9 10