Isometric Format - Layering

Page: 1 2
ID:2202197
 
Jan 18 2017, 5:26 pm (Edited on Jan 18 2017, 10:10 pm)
It's widely known that BYOND struggles to perform in isometric mode, especially with layering. It becomes a very difficult task to make a isometric map to the level of comparable quality with that of what you would get out of TOPDOWN format. We can take these walls for example,



Now, this is the biggest concern. Without excessive use of plane, things begin to get drawn on top of other things, this wall for example has a lower layer than the mob, but it is drawn on top of it because of it's position in the isometric diamond.

Atoms inside the isometric diamond are drawn on top of each other because of their position. Think of it in the way of this illustration:

This means you are forced to set an atoms plane to make it appear over the last atom in an appropriate way, otherwise you get the issue as presented in the last example.

And so, in the most usual case, planes are the most commonly thought of solution, except, they aren't that useful. With the current implementation of plane, big atoms become useless if you're dealing with objects like trees for example, or anything outside of single tile (32x32) like the aforementioned wall and this becomes an issue:



It has become impossible to make a quality world with the isometric format as it sits today. I spoke with several devs that say they actively avoid developing in isometric simply because of the headache it entails with how much overhead it creates. I'd love to see it expanded or at least more layering features implemented to make isometric format less of a pain in the ass to work with.

If you have any work arounds or ideas on how to implement a way of getting around the issues presented, it'd be a great help if you could comment below.
Jan 21 2017, 9:13 pm
One workaround (if that) that comes to mind is setting the layer to match the X/Y location so anything above and below you is always above and below you or w/e
Jan 22 2017, 4:50 am
One workaround (if that) that comes to mind is setting the layer to match the X/Y location so anything above and below you is always above and below you or w/e

Isometric format doesn't obey layering like topdown map does. Give it a shot yourself to see how fucked it is.
Jan 22 2017, 12:09 pm
It's a major roadblock now in the development of Z Tactics and so it would be very helpful if the layering for isometric format was improved
Jan 22 2017, 2:47 pm
Pretty much the isometric format was a 'lets see if this works' experiment years back that never quite panned out. I'm surprised it's officially supported at all with how poorly it works overall.

Lummox hasn't shown a ton of interest in messing with it either, and I don't really blame him. So don't expect any fixes to come soon, if at all.
Jan 22 2017, 3:40 pm
Well that's disheartening to hear after coming this far in development.
Jan 22 2017, 5:35 pm
In response to Crazah
Crazah wrote:
Well that's disheartening to hear after coming this far in development.

If Isometric was a requirement you should've done a bit more research instead of development, would've saved you time and the disappointment.
Jan 22 2017, 5:44 pm
In response to A.T.H.K
A.T.H.K wrote:
Crazah wrote:
Well that's disheartening to hear after coming this far in development.

If Isometric was a requirement you should've done a bit more research instead of development, would've saved you time and the disappointment.

It's not fair to say that though, especially when Isometric Maps are technically still supported. If Lummox isn't planning on fixing what's broken he needs to make the feature obsolete and officially stop supporting it.

Considering Z-Tactics itself looks like a quality game, it's in his best interest to do what he can to aid them in improving the functionality of isometric maps.

Land of Fire and Severed Worlds has already left BYOND due to limitations. BYOND isn't in a good spot right now and there are very few competent developers left using the engine. You don't want to push them away.
Jan 22 2017, 6:03 pm
This could be fixable if you disable all of the layering that BYOND attempts to do for you with isometric format and instead use BACKGROUND_LAYER for everything. This would essentially kick the world into topdown mode.
Jan 22 2017, 11:40 pm
Then why even be in iso map mode in the first place?
Jan 23 2017, 12:36 am
In response to MisterPerson
MisterPerson wrote:
Then why even be in iso map mode in the first place?

Yep. That's about the only summary I can think of.
Jan 23 2017, 6:28 pm
It would be wonderful to hear an official response about this as it's a serious roadblock in our development.
Jan 31 2017, 6:28 pm
Bump.
Feb 2 2017, 11:59 am
I actually do have an interest in improving isometric layering; it's been back-burnered for a while but it's something I keep coming back to from time to time. The trick is, it really needs to use topological sorting, and I need to revisit the algorithm I had for that to one that will be much more performant.

It would also be helpful to have test cases that show the problems in action so that it's easier to solve. That wall issue above for instance: What are the layers involved, and what are the player's bounds set to? The bounds are actually taken into account in iso and side layering.
Feb 2 2017, 12:21 pm (Edited on Feb 2 2017, 12:29 pm)
In response to Lummox JR
Thanks for the response.

Here's the information you asked for,
World
    icon_size = 64

Player
    layer = 11
    bound_height =39
    bound_width =19

Wall
    layer = 8
    pixel_x = 30
    pixel_y = 32


Now I'm not sure if x-pos and y-pos are used in sorting the objects in isometric format, but in my investigations with creating my own isometric drawing algorithm that was the immediate fix. Since both the wall and the player in the aforementioned example share the same y-pos, as far as standard iso sorting they are layered identically.

Additionally, I'd like to bring up some other issues that are present with isometric formats. It seems the renderer jitters around randomly when it encounters a lot of objects on screen with pixel offsets. Pixel offsets also reduce preformance dramatically, sometimes falling from 60 fps to under 10. Which makes it hard to make detailed environments without odd workarounds.

Feb 2 2017, 12:48 pm
The pixel offsets for the wall are problematic. I would highly advise against that for x/y, and stick with w/z offsets instead.

For the bounds, it seems like you should be setting bound_x and bound_y for the player, especially if their icon is centered (as one would assume).
Feb 3 2017, 11:44 am (Edited on Feb 3 2017, 11:55 am)
Right, this seems to actually work, thanks very much!
It would be very cool to have a comprehensive documentation on how the isometric format works internally, I had no idea bounds influenced how objects are sorted for drawing.


Is there any reason why the renderer bogs down when it encounters dozens of objects with pixel offsets?

Here's a poorly done .gif of what I'm talking about. You can see it bog down once I reach the clearing.
Feb 3 2017, 1:00 pm
It'd probably be easier to get you an answer on that with a test environment.
May 21 2017, 12:26 pm (Edited on May 21 2017, 6:21 pm)
So after more fiddling, I think I can safely return to this. It's still an issue, with frame drops happening in certain areas. It is definitely most apparent when moving under pixel movement.

I can assemble a test project and page it to you if you're still open to taking a look.

EDIT: I've tested removing all other tiles on screen, save for just regular turfs minus their pixel offsets and the issue is still present.

https://puu.sh/vXe3s/ca4e7ae8f8.mp4
May 23 2017, 11:21 am (Edited on May 23 2017, 12:27 pm)
Update: with different combinations of world.fps & client.fps, the stuttering problems still occur. We've also tested on various machines of different capability and all of them stuttered randomly while playing.

It seems to clog the command queue DreamSeeker uses as well since the user's input will be delayed the entire duration of the frame skip.

EDIT: Odd behavior update. We tested increasing the world's map size from 100x150 to 200x200 and removing the blank project default /turf/ that took up most of the map and that resulted in performance gains.

Additionally, we dropped /area to a plane of -100 and that resulted in additional performance gains.

EDIT 2: Some of our turfs were 64x128 when our world.icon_size is 64. Trimming these down to 64x64 or into two icons significantly increased performance.
Page: 1 2