Pixel Movement

Page: 1 2 3 ... 5 6 7 8 9 10
Jun 23 2011, 9:30 am
Falacy wrote:
It can be quite meaningful in animated icon states. When you swing a sword or something, you would want to know when and where that sword collided with an enemy.

A collision doesn't occur just because pixels are overlapping.

The problem is not that the questions Lummox posed cannot be answered, the problem is that there is rarely a single answer that would satisfy everyone. Saying "bump is called on the lower atom" is easy, but it has consequences that aren't desirable.

Another big question is: how does the default movement scheme work and what new procs need to be added to allow for customization of movement?

Bravo1 wrote:
The problems arise when games with multiple other features are in question. I'm currently working on a project that's trying to incorporate more dynamic lighting and, even running a 3.6ghz cpu I suffer very low framerate.

Built-in support for client side lighting is the better solution. You'll have this problem whether pixel movement is built-in or not. The server is still handling the movement, so it'll still have increased CPU costs above the basic tile-based, 10 fps game.

To some extent this is a non-issue. You will always be able to find a large enough set of features that cannot all be feasibly implemented in the same game. BYOND games will run unto this problem earlier than other games, but its an issue that any game development environment can have.
Jun 23 2011, 2:53 pm (Edited on Jun 24 2011, 10:17 am)
Forum_account wrote:
A collision doesn't occur just because pixels are overlapping.
It surely can, and is the most sensible way to handle it in various situations (like the one I've already listed). Flash's hitTest takes a simple boolean argument to determine whether it uses per pixel hit detection or a bounding/hit box. Example, obviously that would be somewhat lame/inaccurate if you were just running the detection based on a rectangle. And unless BYOND added some highly functional rotation features, it would be failish to try and pull off hit-box based hit detection in most situations.

The problem is not that the questions Lummox posed cannot be answered, the problem is that there is rarely a single answer that would satisfy everyone. Saying "bump is called on the lower atom" is easy, but it has consequences that aren't desirable.
I listed several possibilities. If it just returns a list then the developer can handle it however they want. As I said, he should play around with it to determine which way works best, the other alternatives should be easy for developers to handle, this is no different than half of the features currently implemented.

Another big question is: how does the default movement scheme work and what new procs need to be added to allow for customization of movement?
It shouldn't need any new procs and should work almost identically to how it does now. It also shouldn't need anything additional for customization, but should automatically become 32x more customizable. The only real question about the base movement is how to maintain speed without needing to destroy the game by altering tick_lag.

Built-in support for client side lighting is the better solution. You'll have this problem whether pixel movement is built-in or not.
This depends quite heavily on how you're calculating lighting. A global lighting system shouldn't benefit from client sided processing. And there's a chance local lighting would just make the clients lag themselves instead of the entire server - yielding similarly fail results

The server is still handling the movement, so it'll still have increased CPU costs above the basic tile-based, 10 fps game.
Why? You're still only moving once per tick

To some extent this is a non-issue.
From the sounds of it, your pixel movement is wasting 10% CPU per player, even with optional efficiency systems enabled. Sounds like a pretty big issue to me.

You will always be able to find a large enough set of features that cannot all be feasibly implemented in the same game.
And that number of features here is 2?

BYOND games will run unto this problem earlier than other games engines, but its an issue that any game development environment can have.
The problem is that BYOND runs into it on the most basic of features, like movement? Unity can run such features at 1,000 FPS (while rendering a fully 3D scene), but BYOND can barely handle them at 10?
Jun 24 2011, 6:36 am
With a 2.5D view, icons often overlap and no collision should occur.

Falacy wrote:
The only real question about the base movement is how to maintain speed without needing to destroy the game by altering tick_lag.

Pixel movement is already possible, so one of the few ways to justify the feature request is to say that performance would improve. To do that, you'd have to answer the question you mentioned there.

You'd also have to explain how performance can increase when the movement procs can be overridden - if it's executing developer-written DM code, why is it not possible for a library to match the performance?

Most servers would struggle to support 50 players in an action game (that uses the default tile-based movement) without having terrible ping times. Up the framerate to 30 fps (which is still low by contemporary standards) and you're down to 17 players per server. You're very concerned with how many players can be on one server, and that's a separate issue from how players move. You're asking for pixel movement and you're asking for it to be awesome. Just adding pixel movement doesn't make it efficient and awesome. Maybe you're better off asking for some general improvements to BYOND that would benefit all user-made features.

It shouldn't need any new procs and should work almost identically to how it does now.

What would be the default behavior that happens when a player presses the up key? What proc gets called? Current procs like Move and step don't really make sense when you're not moving a whole tile at a time. How would you make a mob move by a specified number of pixels? Currently movement is limited to 8 directions, would that still be the case?
Jun 24 2011, 8:03 am
Forum_Account wrote:
if it's executing developer-written DM code, why is it not possible for a library to match the performance?

Well, the engine itself uses the code you give to make the game, yes, but the built in code will always run faster. The code you provide in a dm file is read by the engine and then applied to it's built in code to produce a result. If pixel movement is built in to match the engine then it doesn't have to take the extra step.

Or at least I would assume that's the way things work in this case.

On a side note:
Remember kids!: Putting your text in bold means you're 100% right, 100% of the time! =D

Jun 24 2011, 8:09 am
Bravo1 wrote:
Remember kids!: Putting your text in bold means you're 100% right, 100% of the time! =D

Wrong. You didn't bold it.
Jun 24 2011, 8:19 am
Bravo1 wrote:
Forum_Account wrote:
if it's executing developer-written DM code, why is it not possible for a library to match the performance?

Well, the engine itself uses the code you give to make the game, yes, but the built in code will always run faster. The code you provide in a dm file is read by the engine and then applied to it's built in code to produce a result. If pixel movement is built in to match the engine then it doesn't have to take the extra step.

What FA is referring to is that if you have a custom Move() routine anyway and that's running every time there's a pixel movement, that's going to be pretty much no difference performance-wise than if you handle the pixel movement in soft code already.

Frankly I think the bigger issue here in terms of pixel movement is that it's based on the Appearance system. Any new pixel offset generates a new Appearance. This isn't necessarily ideal. The internals required to handle that do use up some cycles. If movable offsets at least could avoid using this system, it would be a huge boon, though this wouldn't work for older clients or save server load in those cases. To be honest I'd love to find a way to do that though, and combine it with Falacy's other idea about allowing the movement state to be forced on by soft code. Then even if a library has to handle pixel movement, it will have improved performance overall.
Jun 24 2011, 9:24 am (Edited on Jun 24 2011, 9:38 am)
Yes, that's what I meant. Movement routines are fast in games that use tile-based movement because they're simple. Even when you overload all of the movement procs, executing the custom DM code is not a CPU hog (because the code is simple and it's called infrequently). For built-in pixel movement to be useful (extensible) you'd need to be able to override its component procs, so the speed benefit idea goes out the window. It'll be just as fast (or slow) as a user-made implementation could be.

I'm not sure if forcing a movement state is what you want. The ability to play a looping animation from the start would allow this to be done and would be more general. It would let you do things like: if the player is holding down the run key when they start moving, play the run animation from the start, if they're not holding the run key play the walking animation from the start.

Can you explain what an Appearance is? I don't know what you're taking about.
Jun 24 2011, 9:40 am
Forum_account wrote:
Can you explain what an Appearance is? I don't know what you're taking about.

In a nutshell, an Appearance is everything about the physical appearance of an atom or a component of one. It has information about the icon, state, text, name, direction (this can be overridden by other things), layer, overlays and underlays, verbs, mouse pointers, opacity and luminosity and other visual doodads, and pixel offsets. Whenever you add an item to atom.overlays, two things happen: 1) An Appearance snapshot is taken of what you're adding, and that's what gets added to or subtracted from the overlays. 2) Adding to the overlays creates a new Appearance for the main object, since it has a different list of overlays. (If you loop through an overlays list and use the \ref macro you'll see that they use a different internal type than atoms; however the : operator can access most of their vars on at least a read-only basis.) As another example, if you change mob.icon, a new Appearance is generated if necessary and assigned to the mob.

Appearances are sent to the client on an as-needed basis, if the client doesn't have them already. Any client that knows about the appearance counts toward its refcount, and it won't be recycled until nobody is left who knows or cares about it. Clients also periodically tell the server about appearances they don't need to hold onto anymore.

The speed problem I'm referring to here is that Appearances also contain pixel offsets. This is a good thing because it lets overlays have pixel offsets, but if you change the pixel offset of a mob it would probably be more sensible to just send an update of the offsets and send a "neutral" appearance with no offsets or at least just the defaults. If the server didn't have to create a new Appearance for these cases, it would be able to skip a few steps like trying to find if an Appearance with the correct offsets already existed and if not creating it. In a game with lots of pixel movement, this can obviously happen frequently, more so than say a change of direction. The speed benefits might be subtle but with lower tick_lag I think they may come into play more and more. This also could translate into bandwidth savings as the offsets could represent just a six-byte bump per atom instead of sending a whole Appearance to the client, with the only downside being that in theory Appearances wouldn't need to be sent after a while but the offsets still would.
Jun 24 2011, 9:49 am
Doesn't sound like much of a downside at all. Should I make a feature request for this?
Jun 24 2011, 9:52 am
Eh, it probably couldn't hurt. I've been thinking generally of what can be done to improve on pixel movement and I think this is just one minor thing that can help in that arena. That would be a more specific request than this one and it would save me from having to post a new one just to close it if I implement it.
Jun 24 2011, 10:56 am (Edited on Jun 24 2011, 11:26 am)
Forum_account wrote:
With a 2.5D view, icons often overlap and no collision should occur.
That is dependent on the developer. Most current BYOND games are 2.5D, but don't use partially overlapping hit detection, if anything they use the opposite, overly large hit-boxes. Even if you did want to have more sensible overlapping hit detection, for say a player walking up to a wall, you would accomplish that by simply setting a smaller hit-box near the feet of the player. However, if that player were to swing a sword, you would still want per-pixel hit detection (on both the player/target and the sword), or at least a somewhat accurate hit-box matching the animation of the sword, and the body size of the player/target. Otherwise you would end up swinging your sword through the players/targets face and never actually hitting them.

Pixel movement is already possible, so one of the few ways to justify the feature request is to say that performance would improve.
Performance isn't an issue here. The difference between something being built in, and having us handle it ourselves is usually negligible. The fact that your pixel movement library performs poorly is a problem with your library, and isn't really surprising considering the other code that I've seen from you.

To do that, you'd have to answer the question you mentioned there.
My comments about tick_lag destroying games don't refer to performance, they refer to how changing tick_lag destroys all animations and timers. I think we've already discussed solutions for this here as well, but they could implement a version of tick_lag that only effects how often things can be called, without changing animation speeds or sleep() times (IE: doesn't effect actual ticks), or they could implement a more flexible set instant setting.

You'd also have to explain how performance can increase when the movement procs can be overridden - if it's executing developer-written DM code, why is it not possible for a library to match the performance?
As I said, increasing performance isn't part of the request. As for overriding movement, that shouldn't make much of a difference one way or the other. You're still only moving once per tick with current implementations.

Most servers would struggle to support 50 players in an action game (that uses the default tile-based movement) without having terrible ping times. Up the framerate to 30 fps (which is still low by contemporary standards) and you're down to 17 players per server.
That depends almost entirely on the server specs, and assuming the game is programmed efficiently. My games easily handled 100+ players per server without even coming close to stressing world.cpu or network limitations.

You're very concerned with how many players can be on one server, and that's a separate issue from how players move.
Why yes, player counts and movement are indeed separate concepts, how astute of you?

You're asking for pixel movement and you're asking for it to be awesome. Just adding pixel movement doesn't make it efficient and awesome. Maybe you're better off asking for some general improvements to BYOND that would benefit all user-made features.
I'm sure that if I looked through my other requested features that I could find plenty of those. I would even include this one, though it is on a much grander scale.

What would be the default behavior that happens when a player presses the up key?
They move up? What a MIND BLOWING concept?

What proc gets called?
The same ones that already do. I believe we've already talked about how Entered() could be handled in the comments here. For the most part, it would be nearly identical to how tile based movement works, though.

Current procs like Move and step don't really make sense when you're not moving a whole tile at a time.
Why not? step() seems like it would still make perfect sense, my pixel movement systems made use of it as such. Move() would still work just about the same as well, except the "new turf" argument may return the same turf that you're already in. If they wanted to include some sort of tile_step() functions, then I guess that would be acceptable, but pixel movement would allow us to easily create such procs ourselves with a simple loop - unlike trying to go backwards from tile to pixel movement.

How would you make a mob move by a specified number of pixels?
Well, a variable for pixel step size would control how many pixels they move in a single step(). If you wanted to move them further than that, you would just move them multiple times? If you wanted to move them an alternate distance, or a smaller one, you would modify their step size variable and then do the move.

Currently movement is limited to 8 directions, would that still be the case?
For the most basic movement, similar to what already exists, yes. However, that's why I specifically noted the need for a function to move things at angles, and to calculate the angles between things.
Jun 24 2011, 7:03 pm
1.On an isometric map, collision should be detected from only the bottom of an atom. (for flat objects, mobs, etc) and the entire shape if it's a "full" atom (cubes, walls, etc)

2.If the library performs poorly it's because of it's stress on the cpu. If performance isn't going to increase by making it built in then why do it? Basically, if making it built in isn't going to solve it's largest issue then why is it a surprise that it's being so fiercely scrutinized?

3.Sleep isn't affected by tick lag, only frame delay, which should be changed to work like sleep does (decimals are allowed/not restricted to tick_lag).

4.Performance increase would be nice, but I agree, just being able to configure movement/icon states more easily would be a godsend for p_m.

5. It depends mostly on the system it's run on. You'd be surprised how many servers are running 2.5 dual cores, and because byond is single-threaded, it runs faster on a 3.6 single, even though most other processes would be faster on a 2.6 dual.

6.If movement restricts player count because of how it works, then it's a big issue.

7. I agree, a lot of small benefits have been passed over due to negligibility. However if all were implemented by this point, byond would be a lot more streamlined (alghtough it wouldn't be as far along as it is, considering the time it would take to add them).

8. Sometimes up would be used to jump. (but that's a simple override)

9. Some people may want Enter() to be based off the bounding box of a non-dense object to allow more accurate detection from Enter() when using non-square shapes.

10. Step() would have to conform to a standard if being added to a pixel based system. instead of Step() and tile_Step() it'd be better to have Step() and add px_Step() since it would require you to rework how step works. (because this wouldn't break all the old games that still use Step() )

11. pixel_step_size is perfect for this, though some people may want different pixel_step for x,y,(or z) when it comes to movement. (z being for isometric maps that manipulate pixel_z)

12. Calculating angles is pretty easy as it is, the issue is how to turn the icon properly to match that if you're going to use it in that way. Since clients now process the Turn() proc it is much faster than before, but Turn() in itself operates poorly and has very rough results. One reason is that turn() goes from the current icons state. For example: Two turns of 5 degrees has much less quality than a single turn of 10 degrees. I suggest a new variable for icons: angle. Which would make the results of Turn() much more efficient if they would process turn() as an addition or subtraction to the icons angle and then being reprocessed from the icons initial angle(0).

Basically, with each turn you lose quality, so saving the angle of the icon will allow you to modify the angle and then turn the icon from and angle of 0 to result in only a single turn to the icon, which looks much better than multiple turns.
Jun 24 2011, 7:54 pm (Edited on Jun 25 2011, 12:05 am)
Bravo1 wrote:
1.On an isometric map, collision should be detected from only the bottom of an atom. (for flat objects, mobs, etc) and the entire shape if it's a "full" atom (cubes, walls, etc)
9. Some people may want Enter() to be based off the bounding box of a non-dense object to allow more accurate detection from Enter() when using non-square shapes.
It shouldn't be an all or nothing setting. Both (or more?) hit-detection options should be included, and applied to whichever situations best fit your gameplay scenarios

2.If the library performs poorly it's because of it's stress on the cpu.
That sounds somewhat backwards. The library is stressing the CPU because it isn't written efficiently, not because your CPU is already stressed out and just happens to be trying to move a pixel.

If performance isn't going to increase by making it built in then why do it? Basically, if making it built in isn't going to solve it's largest issue then why is it a surprise that it's being so fiercely scrutinized?
For all the reasons that libraries are fail, plus the chance of making BYOND games in general less fail. Also, performance isn't the "largest issue" with pixel movement, it isn't even an issue at all if the systems are coded properly. The largest issue with pixel movement (or lack thereof) is that pixel movement makes almost any genre of game better.

3.Sleep isn't affected by tick lag, only frame delay, which should be changed to work like sleep does (decimals are allowed/not restricted to tick_lag).
4.Performance increase would be nice, but I agree, just being able to configure movement/icon states more easily would be a godsend for p_m.
You appear to be right about sleep() not being destroyed by tick_lag, but decimals in sleep() are automatically rounded down. Definitely seems like something that they should fix in animation timing then.

5. It depends mostly on the system it's run on. You'd be surprised how many servers are running 2.5 dual cores, and because byond is single-threaded, it runs faster on a 3.6 single, even though most other processes would be faster on a 2.6 dual.
Maybe, if you're only running a single BYOND server, and nothing else, then that might be the case. But in most situations, multiple cores are going to give you superior performance even if each core is slower.

6.If movement restricts player count because of how it works, then it's a big issue.
If you're again somehow linking this to performance, then again, this is just because of inefficient programming methods. Pixel movement should in no way be wasting 10% per player of your game's processing power for basic movement.

7. I agree, a lot of small benefits have been passed over due to negligibility. However if all were implemented by this point, byond would be a lot more streamlined (alghtough it wouldn't be as far along as it is, considering the time it would take to add them).
That entire thing just sounds wrong. Small features would streamline BYOND? BYOND is "far along"? How would it take a long time to implement simple benefits, especially compared to how much time they waste on worthless crap like isometrics?

8. Sometimes up would be used to jump. (but that's a simple override)
Jumping is still moving up...

10. Step() would have to conform to a standard if being added to a pixel based system. instead of Step() and tile_Step() it'd be better to have Step() and add px_Step() since it would require you to rework how step works. (because this wouldn't break all the old games that still use Step() )
No, px_step() would be foolish, unless you somehow plan on having a game that uses pixel based and tile based movement at the same time. It wouldn't break any existing games, it wouldn't even have an effect on them, because it would only be active if you've set your game to use pixel movement (which should be the default for all new projects). When you step() in a pixel movement based game, you want to move based on pixels. There's no reason to have a tile_move, because your gameplay wouldn't function around tiles. And if you did need tile_movement, you could very easily make it yourself based on the pixel movement in like 4 lines of code.

11. pixel_step_size is perfect for this, though some people may want different pixel_step for x,y,(or z) when it comes to movement. (z being for isometric maps that manipulate pixel_z)
Sensible

12. Calculating angles is pretty easy as it is, the issue is how to turn the icon properly to match that if you're going to use it in that way.
Finding them is somewhat simple, though it does take a bit of calculating. Moving something at an angle, though, is much more complicated, and with BYONDs current tile based movement, it might as well be impossible.

Basically, with each turn you lose quality, so saving the angle of the icon will allow you to modify the angle and then turn the icon from and angle of 0 to result in only a single turn to the icon, which looks much better than multiple turns.
That is already easy to pull off. If they were to implement some way to handle this, aside from just an atom.rotation variable, it would most likely be even more complex than just handling it yourself.
Jun 25 2011, 5:32 am
Bravo1 wrote:
6.If movement restricts player count because of how it works, then it's a big issue.

Pixel based movement is just more complex and the most efficient implementation will still take up more CPU time. What really limits the player count is the increased framerate. With the server handling everything, there's no way around this. If each client handled their own movement and sent position updates to the server you'd see better performance, but this would be quite a change.

11. pixel_step_size is perfect for this, though some people may want different pixel_step for x,y,(or z) when it comes to movement. (z being for isometric maps that manipulate pixel_z)

I'm not sure what you're describing here. What happens when a player is waking on a conveyor belt? If the player normally moves 4 pixels per tick but the conveyor belt makes them move to the left one pixel per tick, the player should move 5 pixels per tick when walking left and 3 pixels when walking right. How do you capture this with just pixel_step_size?

How would this work for a sidescroller? As the mob falls faster and faster you'd increase pixel_step_size, but they can move horizontally too, and you wouldn't want this to affect that.

I suggest a new variable for icons: angle. Which would make the results of Turn() much more efficient if they would process turn() as an addition or subtraction to the icons angle and then being reprocessed from the icons initial angle(0).

I'm not sure what this has to do with the other things, but similar feature requests have been made. I think I've requested it too, except it'd be an atom var.
Jun 25 2011, 1:56 pm (Edited on Jun 25 2011, 2:15 pm)
Forum_account wrote:
Pixel based movement is just more complex and the most efficient implementation will still take up more CPU time.
Hardly, and it surely shouldn't be using 10% per player. The most complex systems I've ever implemented don't even come close to wasting that much CPU per player. Path finding AIs with a variety of attacks, animations, variables, FoE targeting, etc definitely outweigh basic pixel movement in terms of complexity/CPU usage. Not to mention, pixel movement is just a backwards extension of the movement systems already in place, which use next to nothing.

What really limits the player count is the increased framerate.
Does it? I've never heavily messed with it, but I would think increasing the frame rate of a BYOND game would actually increase performance, or at least yield similar results. Though I would expect it to drastically increase bandwidth usage.

With the server handling everything, there's no way around this. If each client handled their own movement and sent position updates to the server you'd see better performance, but this would be quite a change.
Then you would have people rubber banding all over the place, or not moving at all and then appearing 5 tiles ahead of themselves. Not to mention the hackers galore. And you still have the possible issue of overwhelming low-end clients if you offload everything onto them.

What happens when a player is waking on a conveyor belt? If the player normally moves 4 pixels per tick but the conveyor belt makes them move to the left one pixel per tick, the player should move 5 pixels per tick when walking left and 3 pixels when walking right. How do you capture this with just pixel_step_size?
A conveyer belt wouldn't directly effect movement speed/pixel step sizes. It would just continually move you in one direction. This could be accomplished by modifying the player's step size, moving them, then changing it back to the default. Or, if you weren't concerned with hit detection, you could simply modify their x/pixel_x/whatever variable represents their coordinates. However, if you did want some kind of terrain speed effect (like a hill) you could just setup some turf variables eastSpeed,westSpeed and take these into consideration in Move(). These are developer/game specific issues, however, and shouldn't need much consideration at this level of implementation. How would you handle such scenarios with BYOND's current movement systems?

It could be useful for step() to take an additional parameter for step size. step(atom,dir,distance). This way we could more easily accomplish a conveyer belt type effect without needing to modify the player's step size.

How would this work for a sidescroller? As the mob falls faster and faster you'd increase pixel_step_size, but they can move horizontally too, and you wouldn't want this to affect that.
Which would be the very reason he suggested having the step sizes for x, y, and z as separate values? You could just monitor such values yourself, and modify the step size when movement occurs, but that doesn't seem very effective.
Jun 25 2011, 2:27 pm
Falacy wrote:
I've never heavily messed with it, but I would think increasing the frame rate of a BYOND game would actually increase performance, or at least yield similar results. Though I would expect it to drastically increase bandwidth usage.

If the server has 20% CPU usage when events occur 10 times per second, increasing the framerate to 20 fps means that events can happen twice as often. Some events might not (ex: a day/night cycle that changes state once per minute), but common events (movement, AI loops, etc.) will take advantage of the increased framerate. CPU usage may not jump to 40%, but it wouldn't be far off. I'm not sure why you'd expect performance to increase.

This could be accomplished by modifying the player's step size, moving them, then changing it back to the default.
It could be useful for step() to take an additional parameter for step size. step(atom,dir,distance). This way we could more easily accomplish a conveyer belt type effect without needing to directly modify the player's step size.

That first idea is terrible. DM already has quirky things like winget, it doesn't need any more. For the second idea, I'm not sure why you always want to re-use step() and walk(). Keeping things 8-directional limits what you can do (calling step twice to move up 10 pixels then over 16 isn't the same as making the move in both directions at the same time). Things often aren't thought of as being directional at all. In a top-down racing game you might think of the player's movement in terms of angle and speed, but in a sidescroller you wouldn't.

It seems like you're afraid to say that it'd require a new proc or var. If anything, it'd help your argument to clearly outline what things would need to change, what would need to be added, and how it would all work. You say you've implemented pixel movement before, you should be able to use that to post an example of exactly how you'd want it to work.
Jun 25 2011, 2:59 pm (Edited on Jun 25 2011, 4:41 pm)
Forum_account wrote:
If the server has 20% CPU usage when events occur 10 times per second, increasing the framerate to 20 fps means that events can happen twice as often. Some events might not (ex: a day/night cycle that changes state once per minute), but common events (movement, AI loops, etc.) will take advantage of the increased framerate.
Not necessarily, it depends on how the event is handled. Most recurring events are handled by loops, which are restrained by a sleep(). As Bravo pointed out, sleep() automatically scales against tick lag, so most things would actually be happening half as often, not twice. Well, technically they would be happening at the same speed, but by skipping frames.

CPU usage may not jump to 40%, but it wouldn't be far off.
Except world.cpu is based on % per tick, not % per second.

I'm not sure why you'd expect performance to increase.
Because most events would be happening multiple times less often. You would basically be giving it fluff frames to catch up between processing everything. Though I guess less time to process each action itself?

That first idea is terrible. DM already has quirky things like winget, it doesn't need any more.
That first suggestion isn't even remotely similar to winget? It wouldn't even be any type of built in function...

For the second idea, I'm not sure why you always want to re-use step() and walk().
Because that is the most sensible, intuitive, accessible way to handle the transition. You seem to want them to build pixel movement on top of whats already here, I guess because your library does? Instead of just intuitively integrating it into the current systems. I suppose that's a possible alternative, probably even an easier one, but it would require a different design scheme than what I've been suggesting here.

Keeping things 8-directional limits what you can do (calling step twice to move up 10 pixels then over 16 isn't the same as making the move in both directions at the same time).
You would want a conveyer belt to move you separately, and to move you even if you aren't moving yourself. You could potentially sync it up with a single movement loop, but again, that's developer/game dependent. As for the hill example, that would move you a single time, for a shorter/longer distance.

Things often aren't thought of as being directional at all. In a top-down racing game you might think of the player's movement in terms of angle and speed, but in a sidescroller you wouldn't.
That example seems backwards. You're saying you don't think of movement in a sidescroller as directional?

It seems like you're afraid to say that it'd require a new proc or var.
It most certainly will. Just not pixel alternative procs for all of the tile based ones that already exist.

If anything, it'd help your argument to clearly outline what things would need to change, what would need to be added, and how it would all work.
I included a pretty clear outline in the request itself, and have discussed more in the comments. I suppose I could add such discussed features into the initial request?

You say you've implemented pixel movement before, you should be able to use that to post an example of exactly how you'd want it to work.
Most of my comments here are based on my previously built pixel movement systems. You want me to make a pixel movement library so they can see how it should work? I guess that's a possibility, though it would probably be a waste of time.
Jun 26 2011, 3:27 am
Falacy wrote:
Except world.cpu is based on % per tick, not % per second.
Most recurring events are handled by loops, which are restrained by a sleep(). As Bravo pointed out, sleep() automatically scales against tick lag, so most things would actually be happening half as often, not twice.
Because most events would be happening multiple times less often. You would basically be giving it fluff frames to catch up between processing everything. Though I guess less time to process each action itself?

If no events will happen more frequently, why would you increase the framerate? It's safe to assume that some events are happening more often. In this case, the reason to increase the framerate is to allow for smoother motion, so it's safe to assume that many events will be happening more frequently.

Suppose it takes 30 ms to process all events that occur in the average tick. At 10 fps ticks are 100 ms, so this is 30% usage. Now you increase the framerate to 20 fps. Of the initial 30 ms of processing, 20 ms of that time is spent on events that happen every tick, 10 ms is spent on events with fixed intervals. The new processing per tick is 25 ms (20 ms from the per-tick events, 5 ms because the 10 ms for fixed interval events are now split across every other tick). This bumps CPU usage to 50% (25 ms out of the 50 ms tick).

world.cpu isn't the best way to measure this because it only counts the time spent running procs. The server does more than that. It spends time managing network connections - reading messages from clients, formatting and sending messages to clients. These events will always happen more frequently when you increase the framerate.

That example seems backwards. You're saying you don't think of movement in a sidescroller as directional?

There are directions, but you don't think of the player's movement as being an angle and magnitude like you might for a racing game, so a movement proc that takes a direction and distance wouldn't work. If the player is moving 4 pixels per tick to the right and falling at a rate of 7 pixels per tick, to perform the move you wouldn't compute the angle and magnitude of their move and call "step(atom,dir,distance)". You also wouldn't store their velocity as the angle and magnitude (because it'd complicate everything else - to change their velocity you'd have to work back to get the 4 and 7, change those, then compute the angle and magnitude again).

Most of my comments here are based on my previously built pixel movement systems. You want me to make a pixel movement library so they can see how it should work? I guess that's a possibility, though it would probably be a waste of time.

You don't have to create a working library, you can just use it to either post an example of how the code would look or post an executable demo of how it'd run. Instead of being asked a question, then saying "here's an idea for how that could work", just present the complete idea initially. The problem isn't figuring out how to make things work - obviously this is all possible. The problem is figuring out the best way to make things work. Ideas like "step(atom,dir,distance)" and "modifying the player's step size, moving them, then changing it back to the default" would work, but are far from ideal.
Jun 26 2011, 10:28 am (Edited on Jun 26 2011, 12: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.
Jun 26 2011, 12: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).
Page: 1 2 3 ... 5 6 7 8 9 10