client.dir and side-map format

ID:921191
 
Aug 9 2012, 4:47 am
Not a bug
BYOND Version:497
Operating System:Windows 7 Ultimate
Web Browser:Firefox 14.0.1
Applies to:Dream Seeker
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

When using big icons, they behave erratically when changing the client dir. Pixel_y is being calculated incorrectly on both East and South client.dir. South and West client dirs show the object being offset in the opposite direction as it should be, while North and west reflect the accurate pixel offsets.

Numbered Steps to Reproduce Problem:

1) Create a 3-tile by 3-tile icon and assign it to an object.

2) Offset the pixel_x and pixel_y values by -32, in order to center the icon on the tile.

3) Rotate the direction of the client's eye by 90 degrees. Repeat.

Expected Results:

The object should remain centered on its location during all four rotations.

Actual Results:

The object remains properly centered North and West, but not South and East. It seems as though the pixel offsets are not being inverted when they ought to be.
Aug 9 2012, 5:09 am
The values given don't actually make sense. A 3x3 icon will not be centered on a tile by giving it offsets of -32,-32, unless your world.icon_size=61 which you didn't mention. I think I'll need a test project for this, because I've tested pixel offsets in the past and they've worked fine.
Aug 9 2012, 6:30 am
http://www.byond.com/developer/Ter13/ClientDirBugReport

Centered, as in width/2 - tile_size/2.

The demo should demonstrate both of my recent bug reports.
Aug 10 2012, 12:45 pm
So can we call this confirmed, or busted?
Sep 18 2013, 10:04 pm (Edited on Sep 18 2013, 10:18 pm)
I posted a demo for this over a year ago. Can I get you to check out the demo? It very clearly demonstrates that there is something seriously wrong with SIDE_MAP format. (Or my understanding thereof)

This issue does not occur in TOPDOWN_MAP format, but is present in SIDE_MAP format.


TOPDOWN_MAP:


SIDEMAP:


I just want to further highlight this problem:



As you can see, the bottom-left corner of the red and blue object has been placed in the center of the map, but since it is offset by pixel_x and y by -32, the red square covers the central tile of the map.

Under the central tile is a purple turf. If layering was being done correctly, we'd never be able to see that turf.

Let's give it a spin:



It appears that the WEST and SOUTH directions are doubling the pixel offset on their respective axes.
Sep 19 2013, 1:15 am
Okay, here's what I can figure:

offset values as they appear to the user are as follows:

NORTH: -32,-32
WEST: -32,32 (Y axis is inverted)
SOUTH: -32,32 (Y axis is inverted)
EAST: -32,-32

That means, somewhere deep in the bowels of the rendering code, something is inverting the X and Y component of the object's pixel_x values. It also seems to be doing it to step values, and with further testing, I also found that matrix.transform is incorrect on the EAST and SOUTH directions, as opposed to WEST and SOUTH.

In addition, in SIDE_MAP, the layering makes it impossible to adequately rotate large icons, or to perform any kind of Y offsets using the matrixes, thus officially making client.dir completely useless for SIDE_MAP games.

Sep 19 2013, 1:51 am


And just another comparison for good measure.
Sep 19 2013, 6:49 am
On review, I don't think this is actually a bug at all. Based on what I mentioned in the thread regarding transforms, I think you're making an incorrect assumption about the position of the tile. A big icon is always anchored to its logical map loc. In SIDE_MAP, it visually spills over to the west or east the same way it does in TOPDOWN_MAP (though as I mentioned elsewhere, maybe splitting the difference would be wiser), but the visual spillover in the vertical direction will always be to the physical north, so that it doesn't drop below the "nearer" tiles to the south.
Sep 19 2013, 7:18 am
Here's what I'm not understanding: Why are these two map formats discrepant?

I mean, I'm sure there was a reason to have the origin points work the way they do... I just can't for the life of me divine a situation in which it would be useful for it to behave as it does now.

Maybe I have no clue what I'm talking about here, but it just seems plain counterintuitive to me, that pixel offsets are behaving this way on SIDE_MAP.

From the guide:

The side-view map format is used for 3/4 perspective, where the map is basically similar to a top-down view but is usually foreshortened. Just like with isometric projection, tiles that are closer to the bottom of the screen are considered to be closer to the viewer.

I just genuinely don't understand why the coordinates wouldn't be similar to TOPDOWN_MAP format maps, and what possible use having them act this way would be.

I mean, it would be one thing if TOPDOWN_MAP actually rotated individual icons, or objects' render orientations, but they don't... So why?
Sep 19 2013, 7:28 am
In SIDE_MAP, an icon taller than one tile is meant to actually represent a tall object--e.g., a tree or a building. The icon needs to appear above anything that would go behind it, e.g. at a higher physical Y. The base of this object is fixed: It's the object's loc. Offsetting the icon to the physical south, as is the case with TOPDOWN_MAP, would make no sense, as only the top part of the big icon would be visible and the rest would be obscured by ground tiles with a lower physical Y. Alternatively, I suppose it could be considered part of the lower row, but then its footprint really isn't anchored on its loc.

Consider a much simpler example: Instead of worrying about icon width, we'll just have a 32x48 flower pot with an Audrey II growing out of it. This is meant to look a little taller than one tile, but it's only one tile wide, so the overflow in the physical east/west directions is moot. As the map turns, we'd want the flower pot, the base, to always appear on the same tile. SIDE_MAP's positioning rules do this.

As I mentioned though, with wide icons this may be short of ideal. It seems like the bottom center of the icon should always be its base in SIDE_MAP, which would allow for more consistent positioning and also solve the "big tree problem". I'd consider changing this, except I don't know if it would impact any games. If this was the case, the horizontal shifts you see in your transform example wouldn't be happening.
Sep 19 2013, 7:56 am
I'm just completely crestfallen that this:



meets "not a bug criteria."

You know what I have to to get around this? I have to generate 4 icon_states, one for each direction of the wide object, then add them as overlays with pixel offsets for each. Then I have to make sure the right graphics are on the right side of the tree, and the EAST/WEST or NORTH/SOUTH icon_states are blank.

--otherwise, I have to use TOPDOWN_MAP for 3/4ths projection, something that SIDE_MAP is advertised as being, which, in fact, it is not useful for.
Sep 19 2013, 9:11 am
Pixel offsets get rotated with client.dir changes, so that tree with multiple icons is going to get broken up like that regardless. (Transforms, however, aren't impacted by client.dir.) But you'll notice the base of the tree is always in the right place; the rest of the tree just needs to be relative to that.

If the tree was a single icon, a pixel_x=-32 offset would fix everything by putting the base in the right place. Additionally as I mentioned it might made more sense for SIDE_MAP to simply treat the bottom center of the icon as its base. In this case, with the icons separate, it makes more sense to use transform so you have a rotation-invariant way of adjusting the pixel offsets.
Sep 19 2013, 9:57 am
In response to Lummox JR
Lummox JR wrote:
If the tree was a single icon, a pixel_x=-32 offset would fix everything by putting the base in the right place.

Why don't you take a look at my linked demo from a year ago, you'll see that it does not work like you think it does.

Sep 19 2013, 9:58 am
In response to Lummox JR


This image was done with transforms. It does affect both step and transforms.
Sep 19 2013, 12:18 pm
Ah, I was mistaken about pixel_x=-32 being a cure-all for a big tree icon, as I forgot about east-west, where pixel_y would take that over.

I suspect SIDE_MAP really does need something like an assumption the icon is centered at the bottom rather than tying it to a corner, which will give it consistent positioning in the various modes.

Transforms are definitely not affected by client.dir. What you're seeing is that the icon's center itself has been moved, because it's a big icon.
Oct 7 2013, 8:14 pm (Edited on Oct 7 2013, 8:19 pm)
I've had a similar problem as well. Icons that are bigger than the default icon_size sit low, even though they don't have any offset at all. However, at least for me, this problem only persists in the map editor itself.



world
    icon_size = 32

obj
    Well
        icon = 'Well.dmi'
        density = 1


As you can see by the image it's shifted down and cut off, but when the game runs it's where it's supposed to be. The red line is the distance from one pixel above the highest point on the bucket to the well, and the blue line is one pixel below the icon's tile. The purple line is the where the two would be intersected, and it's 19 pixels in both tests, but the well is in a completely different place. I tried it in a brand new environment and it did the exact same thing.

I haven't set a map_format, so it should be using TOPDOWN_MAP format, if I'm not mistaken.

It's also worth noting it didn't do this before I upgraded to 500.
Oct 8 2013, 8:46 am
In response to Reformist
The issue you're reporting is a different one; it's mentioned in id:1393580. The issue Ter13 brought up in this thread is that SIDE_MAP positions things differently than TOPDOWN_MAP, which is actually expected behavior.
Oct 8 2013, 8:47 am
Lummox JR resolved issue (Not a bug)