bounds malfunctioning in SIDE_MAP?

ID:2061712
 
Mar 29 2016, 8:53 pm
Code:
/*
    These are simple defaults for your project.
 */

world
    fps = 25      // 25 frames per second
    icon_size = 32    // 32x32 icon size by default
    map_format = SIDE_MAP
    icon_size = "32x24"
    view = 6     // show up to 6 tiles outward from center (13x13 view)


// Make objects move 8 pixels per tick when walking
atom
    icon = 'icons.dmi'
mob
    step_size = 8
    icon_state = "mob"
    verb
        bounds_test()
            for(var/atom/a in bounds())
                a.icon *= 5
                spawn(25) a.icon = initial(a.icon)
            var/atom/a = loc
            a.icon /=5
            spawn(25) a.icon = initial(a.icon)

obj
    step_size = 8
turf
    grass
        icon = 'grass.dmi'


    water
        icon_state = "water"
        pixel_z = -2
    ground
        icon_state = "ground"
        pixel_z = -2


I'm really thinking I just don't understand SIDE_MAP at all here, but shouldn't this make the tile I'm actually on dark, and the tiles that I'm overlapping (which should be around my actual location) light?

The reason I'm thinking that I'm misunderstanding is because the result this produces is that the tiles that light up go further back as you move up. Which does make sense in a SIDE_MAP game, because the further back you move, the further away from the screen you move.

This behaves as expected in TOPDOWN_MAP format.

This has been causing some major issues with my 3D collision detection. It's working fine until you get half way up the map and you just suddenly fall into the abyss.
Mar 29 2016, 9:10 pm
With world.map_format = SIDE_MAP and world.icon_size = 32, one tile is actually 32x24 pixels in visible size, even though it is physically 32x32 pixels in bounds.
Mar 29 2016, 9:28 pm
I'm pretty sure the problem persists even with world.icon_size = "32x24"

I didn't even know that wasn't set (it's set in my actual project) in the quick demo I made though.
Mar 31 2016, 12:06 am
I don't really follow the issue you're having here. Perhaps an animated .gif to show it?

Also, I can't sleep without fixing this for you:

var/lightmatrix = list(0.5,0,0, 0,0.5,0, 0,0,0.5, 0.5,0.5,0.5)

mob
    verb
        bounds_test()
            for(var/atom/a in bounds()-loc)
                a.color = lightmatrix
                spawn(25)
                    if(!(a in bounds()))
                        a.color = initial(a.color)
Apr 1 2016, 7:42 am (Edited on Apr 1 2016, 7:51 am)
In response to Lummox JR
I apologize for being vague in the OP.

There isn't a problem with the original code, please stop offering suggestions to fix it. The problem is with bounds() (Lummox, your suggestion didn't even fix anything; it broke it, actually)

The challenge is to use bounds() to highlight all turfs found by bounds() with the SIDE_MAP format.

Just try it. It will produce weird effects, at least it is in my BYOND.

http://imgur.com/bCdorVa

The above is an example.

The world is a dirt box with grass on the outside. So basically imagine you have grass tiles on the edge of the map and dirt in the center. Because that's what it is.


Dark tiles are the usr's loc at the time bounds_test was used.

Light yellowish tiles are the tiles actually highlighted by calling bounds().

As you can see, the turfs highlighted by bounds gradually get further away from the turf I am actually standing on, which is shaded.

It's as if my bounds is sliding away from my actual mob.

This effect continues indefinitely, meaning if I move to the top of a 100x100 map, the turfs returned by bounds() will return turfs about 50 tiles NORTH of my actual position.

This became an issue because I was using bounds() to detect tiles below my mob for 3D collision detection purposes, but it was returning turfs halfway across the world, which, I could tell, because I started having the turfs which were supposed to be checked for collision highlighted, and I could see that it was highlighting turfs halfway across the world and no where near my mob.

My code is ugly, but that's literally the entire source code needed to reproduce this problem.

I'm hoping both of you actually copied and pasted it into DM and added icons and ran it before you tried to "fix" the code, because I'm not having a problem with the code -I- wrote.

EDIT: ignore typos going forth, my computer is moving really slow and I honestly cbf to keep waiting 5 minutes to edit my posts, nor could I be to keep waiting for the preview to load up so I can check my spelling and grammar.

EDIT: Also ignore the actual environment, lol. Just focus on the strip of grass on the left. Any grass on the left that's the same color as grass on the right is grass that I did not use bound_test while standing on.

EDIT: I think I'm just going to rewrite this because I keep having to edit it anyways.
Apr 1 2016, 9:56 am
In response to Ill Im
Ill Im wrote:
There isn't a problem with the original code, please stop offering suggestions to fix it. The problem is with bounds() (Lummox, your suggestion didn't even fix anything; it broke it, actually)

My only intention was to get you off of the horrible icon math and onto something considerably more useful. And frankly your loop is really horribly set up, so it's not clear that your problems are separate from that. It's important to work from as clean a surface as possible.

Dark tiles are the usr's loc at the time bounds_test was used.

Light yellowish tiles are the tiles actually highlighted by calling bounds().

As you can see, the turfs highlighted by bounds gradually get further away from the turf I am actually standing on, which is shaded.

It's as if my bounds is sliding away from my actual mob.

This sounds more like it's a function of the terrible loop than of the actual results from bounds(). If you want good results, you're better off printing the results from bounds().

Also, keep in mind that bounds() has zero relationship to the map format. It isn't possible for it to deliver different results in SIDE_MAP vs. TOPDOWN_MAP, because the coordinates being used are logical coordinates, not visual coordinates. Those don't change based on the map format.

The fact that you're seeing different results in TOPDOWN_MAP mean that it's your code that's misbehaving, not bounds().