Pixel Movement

by Forum_account
Pixel Movement
A pixel movement library for isometric and top-down maps.

native pixel movement variables

ID:313617
 
Feb 17 2012, 1:12 pm
Is there a reason, or is it too late, to use bound_x/y and bound_width/height instead of pixel_x/y and pwidth/pheight?
Feb 17 2012, 2:30 pm
Kaiochao wrote:
Is there a reason, or is it too late, to use bound_x/y and bound_width/height instead of pixel_x/y and pwidth/pheight?

I'm not sure what you mean by "too late".

You can use these variables if you'd like. The library, from what I can remember, just sets the bound_width/height vars in the New() proc based on what you set pwidth and pheight to.
Feb 17 2012, 2:44 pm
I mean, you're forced to use pwidth/pheight to set the bounding box's size, and you're forced to use pixel_x/y to set the offset.

Why not just go with bound_width/height and bound_x/y?
Setting bound_x/y causes glitches, and setting bound_width/height doesn't affect pwidth/pheight, only the other way around.
Feb 17 2012, 2:54 pm
I'd rather it be consistent when you use three dimensional movement. The naming of pwidth and pheight is also more consistent with the px and py vars.

The bound_x/y vars aren't necessary. I'd rather not complicate things by supporting them too.
Feb 24 2012, 12:58 pm
How can I place objects on the map with step_x/y using the pixel-placement method?

So far, this works:
// pixel-movement.dm, line 165
atom
    movable
        New()
            ..()
            bound_width = pwidth
            bound_height = pheight

            px += step_x
            py += step_y
Feb 24 2012, 1:04 pm
Setting bound_width and height there shouldn't be necessary. The library defines a constructor that should take care of that.

If you don't want to add to px and py you can use set_pos():

atom/movable/New()
    ..()
    set_pos(px + step_x, py + step_y)
Feb 24 2012, 1:15 pm
movable atoms don't have set_pos(), or a lot of the things mobs have exclusively.

I'm not sure if I fully understand why exactly it is that the pixel movement stuff is mainly for mobs and not just movable atoms, but I think it's probably so world.movement() doesn't have to loop through items laying on the ground, or something. That has been classified as an optimization thing, though.
Feb 25 2012, 2:09 am
Originally I wanted a way to have types of objects that still behaved completely tile-based. If you wanted something to have pixel movement, it had to be a mob. Since the library now makes use of some built-in pixel movement stuff and since BYOND's pixel movement prevents the use of gliding, there's less of a reason to keep things exclusive to mobs.

You are correct that it'd complicate world.movement(). I'm not sure how feasible it is to add a more flexible way of determining which objects have their movement proc called from world.movement. There's probably no effective way for the library to handle it since it can't detect when you do something like "obj.vel_x += 1".