BYOND's pixel movement in depth

ID:151279
 
Nov 9 2011, 3:47 am (Edited on Nov 9 2011, 3:57 am)
Is someone here knowledgeable about BYOND's native pixel movement?

I'd like to incorporate objects with other shapes, say circles. I am currently lost on how I should override the default Move() and other stuff to avoid starting from scratch.

Knowing about the step by step processes of BYOND's native pixel movement would be of great help. Your hypothesis will be greatly appreciated.
Nov 9 2011, 4:05 am
You can find everything you need here.

The basic way to use it is just by playing with atoms that are "movable"(not turfs), and setting the step_size, bound_width, bound_height, etc. Sadly all dense objects can only be squares.
Nov 9 2011, 4:26 am
In response to Kaigne
I am aware of the blog post and the procs/vars related to pixel movement. What I am interested is on how the procs handle stuff from beginning to end, not just the input and output alone.

The old Move() is kinda like this:
atom/movable
    Move(NewLoc,Dir=0)
        if(loc&&!loc.Exit(src))
            return 0
        if(!NewLoc.Enter(src))
            return 0
        // so on

(not really sure about that)

But what about now? What intrigues me the most is the new walk_to().
Nov 9 2011, 4:33 am
There's not much you can do to extend what BYOND provides. All objects are rectangles and collisions are only checked when rectangles begin to overlap. If you wanted to make a circle, you'd have something like this:

            |
            |
            |
+-----------+-+
|    #####  +-+-------------
|  #########  |
| ########### |
| ########### |
|#############|
|#############|
| ########### |
| ########### |
|  #########  |
|    #####    |
+-------------+


You can put the circle inside of a square bounding box and override its Cross() proc to give it a custom collision check, but the Cross() proc is only called when the objects begin to overlap. It's not called after they've already begun to overlap.

In the diagram, the circle's bounding box has started to overlap a wall so its Cross() proc is called. To make it behave like a circle we'd want Cross() to return 1, allowing the objects to overlap like it shows because the wall doesn't overlap the circle. However, this means that Cross() won't be called the next time the circle moves, even if the move makes the wall start to overlap the circle. There's no opportunity to deny the movement based on the circular bounding shape.

You can implement this yourself and probably won't see a big hit to performance. My initial estimate was that native pixel movement had half the CPU usage of soft-coded pixel movement. But, you can use some built-in features to further improve the soft-coded method, making it possible to add new features and still see some performance gain.
Nov 9 2011, 4:47 am
In response to Forum_account
Forum_account wrote:
In the diagram, the circle's bounding box has started to overlap a wall so its Cross() proc is called. To make it behave like a circle we'd want Cross() to return 1, allowing the objects to overlap like it shows because the wall doesn't overlap the circle. However, this means that Cross() won't be called the next time the circle moves, even if the move makes the wall start to overlap the circle. There's no opportunity to deny the movement based on the circular bounding shape.

Yea, that would be problematic. I guess it's the Move() proc that pretty much handles everything. If only the reference states the complete algorithm, I could rewrite it with less problems. *sigh*
Nov 9 2011, 4:50 am
In response to Jemai1
Jemai1 wrote:
Yea, that would be problematic. I guess it's the Move() proc that pretty much handles everything. If only the reference states the complete algorithm, I could rewrite it with less problems. *sigh*

It's almost all handled internally. Even if you knew how it worked you'd still have to implement it all yourself.
Nov 9 2011, 4:57 am
In response to Forum_account
I know that I would need to. Knowing how it works will give me ideas on how to efficiently emulate it. If possible, I would like the walk_to() to do it's job even for circles. I really doubt the possibility though.
Nov 9 2011, 5:06 am
In response to Jemai1
Before adding any of this, I'd strongly consider how much you really need objects to be circles.

Jemai1 wrote:
I know that I would need to. Knowing how it works will give me ideas on how to efficiently emulate it.

There's no way to emulate it because you're doing something it doesn't already do. You can still use built-in collision checking for rectangular objects, you just need to add your collision detection for circles on top of that.

If possible, I would like the walk_to() to do it's job even for circles. I really doubt the possibility though.

If you give the circular mob a square bounding box that completely contains the circle, walk_to() will work but it might not find some paths that a circle would be able to squeeze through.
Nov 9 2011, 10:25 pm
In response to Forum_account
Forum_account wrote:
Before adding any of this, I'd strongly consider how much you really need objects to be circles.

Jemai1 wrote:
I know that I would need to. Knowing how it works will give me ideas on how to efficiently emulate it.

There's no way to emulate it because you're doing something it doesn't already do. You can still use built-in collision checking for rectangular objects, you just need to add your collision detection for circles on top of that.

My first goal for this post is to somehow emulate it. Once I have done that, I'll then add the things I want.

If possible, I would like the walk_to() to do it's job even for circles. I really doubt the possibility though.

If you give the circular mob a square bounding box that completely contains the circle, walk_to() will work but it might not find some paths that a circle would be able to squeeze through.

I thought so too. I guess that might be fine.