Setting Pixel Bounds

ID:1536528
 
Apr 4 2014, 5:25 pm (Edited on Apr 4 2014, 5:36 pm)
(See the best response by Kaiochao.)
I'm curious how some of you go about "pixel accuracy." Say you have an object that has eight directions. You might set its bound variables relative to its north or south direction, but these numbers will not be accurate for, say, its east direction -- at least that's my experience.

I have considered having the object change bounds as it is animating. Something like this:

    proc/cycle_bounds(bound_variable, delay)
        if(args.len > 2)
            for(var/bound in 3 to args.len)
                sleep(delay)

                vars[bound_variable] = args[bound]

            vars[bound_variable] = initial(vars[bound_variable])


The thing about this method is it is time consuming. I'm sure there's an easier way to do this.

Do you guys set the bounds once? Or do you have bounds change with the icon's animation so that it is more accurate? Suggestions and the like are welcome.
Apr 4 2014, 6:37 pm
Best response
The only time I've ever changed bounds in-game was for crouching in platformers. You would need to do certain checks to make sure you don't clip through objects when getting larger.

It's not really practical to be changing bounds to try to perfectly fit the image, anyway.
http://devmag.org.za/2011/01/18/ 11-tips-for-making-a-fun-platformer/:
3. Mind your collision boundaries
The collision boundary of a friendly object is bigger than the object. The collision boundary of a harmful object is smaller than the object. Friendly objects include power-ups, switches, ladders, and swinging ropes. Harmful objects include enemies, enemy bullets, spikes and rotating blades. The bigger collision makes it easier to interact with, or collect the friendly object. The smaller collision makes it easier to avoid the harmful object.
Apr 4 2014, 6:53 pm
That puts things into perspective. Thanks.
Apr 5 2014, 2:20 pm
On a similar note, I'm having a hard time getting this stuff right. I thought I understood how to use bounds correctly but it seems like every time I re-test something, there is another issue.

proc/get_pixel_step(var/atom/A, var/pixels, var/width = 0, var/height = 0)
    var/x = 0
    var/y = 0

    if(A.dir & NORTH) y += pixels
    if(A.dir & SOUTH) y -= pixels
    if(A.dir & EAST) x += pixels
    if(A.dir & WEST) x -= pixels

    return obounds(A, x, y, width, height)


This is what I have been using to determine what collides with certain things. This does not work the greatest, as bounding boxes only expand towards the northeast corner (from what I have tested). So basically it works as long as you aren't facing east, or if you don't use extra width/height at all. Not everything uses the default tile size, so I need to be able to expand the box when needed.

I have been fiddling around with this for a while now and have yet to come up with a solution. I'm starting to wonder if pixel movement is worth the time.
Apr 5 2014, 8:04 pm

Not too sure I follow. You're setting the width and the height, and it only expands northeast? Have you tried setting the bound_x/y?

bound_x : Leftmost offset of the bound
bound_y : Bottom offset of the bound
bound_width : with of the bound
bound_height : height of the bound
Apr 5 2014, 8:40 pm
Basically, I can expand the box via bounds using extra width/height, but, in my experience, you can only expand it one direction. If you put a negative value trying to make it expand a different direction to correctly match the way you are facing, it will not work.

for(var/character/c in get_pixel_step(user, attack_distance))


This is what I use for my simple attack macro. This works because I am not adding any width or height, just offsetting the box.

for(var/character/c in get_pixel_step(user, attack_distance, 32, 32))


Say I changed the code to look like the above. Depending on which way I am facing, this will not produce the desired results. I cannot make the box expand "left" or "down," it will only expand "up" and "right."
Apr 5 2014, 9:49 pm
If you want the box to expand down, you expand up and move down.
Apr 5 2014, 10:10 pm
In response to Kaiochao
I was really hoping it wouldn't come down to that. Maybe bounds/obounds should support negative values for extra width/height, basically turning the bounding box inside out.

Thanks for the help you two.
Apr 5 2014, 10:14 pm
In response to FKI
Negative values for extra width/height makes the box smaller until you get to bound_width/height. At that point it either breaks or extends in the other direction. You should test that and make a feature request if it doesn't already work.
Apr 5 2014, 10:44 pm
In response to Kaiochao
Well that explains why it didn't work as intended the first time I tried it.