Descriptive Problem Summary:
With the map_format set to SIDE_MAP movable atoms don't seem to slide under stationary big atoms correctly. When standing on the same x coordinate as a big atom, then stepping north, the "draw layer" of the moving atom doesn't finally update until its movement animation has completely finished. It slides over the big atom then finally drops a layer and is drawn behind it.
This behavior seems to be reversed when walking south. The moving atom's layer will instantly pop above the stationary big atom when moving south. I've built a demo to help illustrate what I'm trying to describe here. Notice how the red squares instantly pop over the larger object when walking next to it.
Expected Results:
What should happen is having an atom's draw layer update immediately after moving north rather than after its moving animation has completed. The reverse should be so when moving south, the moving atom should remain at its lower draw layer until fully completing its moving animation.
It should look something like this.
Workarounds:
It's possible to get the intended layering behavior I described but, in doing so you throw out some of the benefits SIDE_MAP has to offer.
ID:112978
 May 7 2011, 4:19 pm (Edited on May 9 2011, 9:38 am)
|
|||||||||||||
Not a bug
| |||||||||||||
Other people are reporting the files are downloadable, must have been a temporary hiccup.
As for the EFFECTS_LAYER workaround, it works to a degree but seems to have it's own strange issues. The layer of other objects seem to be effected by your own y coordinate. While north of other atoms they're always drawn under anything on the EFFECTS_LAYER. If you're south of the same atoms they're drawn above EFFECTS_LAYER. Big atoms are always drawn above it, mobile atoms are drawn above it when they move just like I described in the bug report. I've also noticed /images being drawn under big atoms even if the images are on EFFECTS_LAYER. It only seems to happen when your y coordinate is below the two. | |
I found the problem. You typoed both links, putting rsc instead of src.
| |
Oh noes ;.;
| |
I confirmed my suspicion on your demo. The trees you added are in OBJ_LAYER. While the mob is straddling between y and y+1, the trees will be underneath the mob just like they are if the mob is only on y, which is correct behavior. Changing the trees' layer to MOB_LAYER+1 eliminates the problem entirely.
| |
Are you sure there's nothing wrong here?
I've made another demo to show how big atoms are drawn over each other based on pixel offsets rather than y coordinates. | |
Offsetting pixel_y will effectively move an object to a different row. The effective row of an object in SIDE_MAP is y + floor((pixel_y + glide_y) / icon_height).
Your new demo shows the pixel_y being set to -64 (two tiles down) for the east and west directions, and for south it's -160. The north direction puts pixel_y at 32, one tile north of the player, which is therefore one tile further back. All the other directions have a negative pixel_y so they will pull the icon forward from the player. The behavior for every direction, at every level of the trees, is consistent with my predictions. I did find and fix a separate issue, which shows up slightly in your demo. If you stand 2 tiles east of a tree's base and 5 tiles north, face south, and use the Pew verb, you'll see the yellow square on top of the tree's base; in all other cases of standing at y+5, the icon is below the tree. The yellow square should be below the tree as well, and this is not happening because x position was being taken into account inappropriately. | |
Would it be possible to have SIDE_MAP disregard pixel offsets and work solely on x,y coordinates?
| |
Not so much, no. The problem is that while gliding between rows, a mob has to appear as if it's on the nearer row in order for things to be drawn in the right order. Gliding is applied to the regular pixel offsets. That may be separable from the regular offsets with some work, but as a practical matter it's not very feasible and it would also interfere with using pixel-based movement.
pixel_z, however, can be adjusted without any change to the row. The value of pixel_z is not foreshortened (though in your demo that's moot, as the tiles are square) and it does not impact the nearness of the atom in any way. | |
I seem to recall there was more to your demo than that (besides the shadow thing you resolved with EFFECTS_LAYER), so it'll be worth looking at that to compare the results. If the tree is a single icon and it's on a turf layer then the mob should draw on top of it when it's between the y and y+1 rows, or on the y row, but never any other time.