Pixel Movement Layering

ID:1839056
 
Apr 23 2015, 4:22 am
(See the best response by Ter13.)
Code:
mob/player
    bound_x = 9
    bound_width = 14
    bound_y = 3
    bound_height = 22
obj

    tree
        icon = 'Tree.dmi'
        density = 1
        bound_x = 70
        bound_width = 20
        bound_y = 15
        bound_height = 45

atom/movable
    var/base_speed=  8
    var/true_speed= 8
    var/running = 0
    New()
        step_size = true_speed

mob
    proc/Toggle_Speed()
        if(running == 0)
            running = 1
            true_speed = base_speed*2

        else
            running = 0
            true_speed = base_speed

        step_size = true_speed

    verb/toggle_run()
        set name = "Toggle Run"
        Toggle_Speed()


Problem description:

I've been away for a while, and trying to refresh myself on DM coding once again. I remember a couple years back I did a small project that had pixel movement. A problem I remember specifically having was with layering, but I can't recall how I resolved it.

I'd like the mob to layer over the tree when in front of it, but I'd like for it to layer under the canopy when he walks up, rather than on top like in the screenshot.






It seemed like it had something to do with checking which was at a higher Y value on the map and then changing it's layer, but I can't recall exactly how. If anyone could point me in the right direction, that'd be great.

Apr 23 2015, 6:52 am
You would need to either split the tree into pieces or use SIDE_MAP for this. The SIDE_MAP format still has some sorting issues (mostly because the sort is not topological, something I hope to address fairly soon), but it's your best bet for this kind of thing.
Apr 23 2015, 8:12 am
There are a few ways I know of to deal with this. Using the y and step_y values to manipulate layers is a common way to simulate SIDE_MAP without the issues that come with it, but that tends to involve adjusting your mobs layers by less than 1 according to how high their y and step_y values are. Higher y's higher layer, lower y's lower layer.

You'll probably need that just for making mobs layers align correctly when they overlap. As for the tree its self, it won't be fixed by this method. You could chance using SIDE_MAP, but I'm not sure how well that would interact with the above feature, and it definitely doesn't solve the mob overlap issue.

So that brings us to the other options. One is to split trees into two objects, one with the lower layer, and one with the higher. The other is similar and it is to split the tree, but instead of creating a second object simply use the first halves New() proc to add the second half into its overlays. I haven't tested that yet, but I imagine it should work.

I think there may be another option or two, but that is all I can think of for now so hope it helps.
Apr 24 2015, 7:25 pm
Best response
I advocate strongly against SIDE_MAP... I've just found that it's too damn problematic to use.

#define TILE_WIDTH 32
#define TILE_HEIGHT 32

atom
    var
        standing = 0
        base_layer = 0
        layer_mod = 0
    proc
        UpdateLayer()
            if(layer-layer_mod!=base_layer)
                base_layer = layer
            if(loc&&standing)
                layer_mod = ((y-1)*TILE_HEIGHT + step_y - bound_y) / (world.maxy*TILE_HEIGHT)
                layer = base_layer+layer_mod
    New()
        ..()
        UpdateLayer()

atom/movable
    Move()
        . = ..()
        if(.)
            UpdateLayer()


This is a pixel-based approach that I use that's fairly similar to Kaiochao's approach. Never had a single complaint with this approach.
Apr 24 2015, 7:38 pm
Well the problematic part is the layer sorting, which I'm hoping to get fixed soon. In fact I have some notion of fixing it in 508; I have an algorithm I've been working on as a side thing that should handle topological sorting much more nicely.