Descriptive Problem Summary:
When map_format = SIDE_MAP and non-square icons being used, there is a display glitch. It's not a layering issue and it doesn't happen when map_format is TOPDOWN_MAP, so it seems to be a bug. It seems like internally, some calculation is using the icon width when it should be using the icon height.
Numbered Steps to Reproduce Problem:
Download and run this demo.
Expected Results:
The mob and camera should remain in the same place.
When you're at 1,1 and the mob (and camera) are offset 16 pixels up, you're at the same position as if you were at 1,2 and shifted 16 pixels down. The demo has two verbs, each sets you to one of those configurations. You shouldn't notice a difference.
Actual Results:
The mob appears in different positions. The first configuration (1,1 + 16 pixels up) is correct, but the other configuration puts the mob too low on the screen (looks like 8 pixels too low).
Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?
When does the problem NOT occur?
The problem only occurs when map_format = SIDE_MAP. It works fine with TOPDOWN_MAP.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Workarounds:
ID:117817
 Aug 29 2011, 12:42 pm
|
|||||||||||||
Not a bug
| |||||||||||||
|
Aug 30 2011, 5:12 am
|
|
Lummox JR
   |
Per documentation, in ISOMETRIC_MAP and SIDE_MAP formats, pixel_x/y act along the "ground". When you use a tile size of 24x32, SIDE_MAP expects this is actually 24x24 with foreshortening (even though this actually is the exact opposite of foreshortening, which would be more like 32x24). Your pixel_y of ±16 is actually being scaled to ±21 for display purposes.
|
SIDE_MAP shouldn't make assumptions about the "ground size", it should use world.icon_size as the ground size. If it assumes the ground is 24x24 when icon_size is 24x32, how do you make tiles where the ground is actually 24x32? Won't it always handle it wrong?
If I wanted the ground to be 24x24 and have tiles overlap their neighbor to the north a little, I'd set world.icon_size = 24 and make a .dmi file with icons that are 24x32. | |
SIDE_MAP is designed with the concept of foreshortening in mind; it is intended for 3/4 projection. ISOMETRIC_MAP likewise makes assumptions about ground size, and the two modes are similar in many ways.
| |
With isometric icons the "ground" is a diamond shape inscribed in the rectangular tile size and you have to make assumptions about it because there are many different diamonds that could be inscribed in a rectangle. For example, tiles that are twice as wide as they are tall would have the same rectangular bounds as tiles that are twice as tall as they are wide. With SIDE_MAP you don't have you make any assumptions because the icon size is a rectangle.
This makes more sense to me now. I understand why the program behaves the way it does but I don't understand why you'd write the program to behave that way =) | |
Look at it from the point of view of someone trying to develop a 3/4 perspective game. Counting pixel offsets along the ground is simply easier, but it's also the only way to assure proper behavior if the map is rotated via client.dir. Counting pixel_x/y as relative to the perspective was a change made for ISOMETRIC_MAP and doing things differently for SIDE_MAP--which is intended to be a perspective projection also--would be inconsistent. The use of a 24x32 tile size in this mode is very unusual.
| |
I thought that made sense, but it only makes as much sense as client.dir does and that doesn't make much sense at all. Wouldn't you always have this problem with rotating client.dir when the tiles are non-square? For example, a 3x1 tile room with 64x32 icons is 192x32 in pixels. Then you rotate client.dir by 90 degrees and it's 64x96 in pixels.
The use of a 24x32 tile size in this mode is very unusual. I don't think this tile size is likely, but someone did run into this problem. | |