Icon Layering Question

A place to record your ideas for the game.
Post Reply
nullbear
Joined: Tue Apr 26, 2016 11:32 pm
Byond Username: Nullbear

Icon Layering Question

Post by nullbear » #476067

Coders, answer me this:

Before I get into trying to make some big change or whatever,
Is there any reason that I couldn't/shouldn't rewrite layers so that atoms with a higher Y coordinate are rendered on a /slightly/ higher layer?

Post Related: https://tgstation13.org/phpBB/viewtopic.php?f=9&t=21602

Currently, virtually ALL turfs are on Layer 2. All objects on layer 3. And all mobs on layer 4.
This means that you can never have an object that obscures a mob. Which is intentional, balance-wise. But i feel it also restricts the 3/4 perspective view of the game, preventing you from having objects which appear to have any sort of "Z" dimensionality to them. In the above post, i tweaked the layer and pixel-y variables a bit to show an example of how it COULD look if the layering system was changed.

What i'm considering is making a subtle but big change to the way objects are layered.

Turf's are rendered on layer 2, Plus 0.02 * y, where y is the y coordinate of the turf.

Objects at the back edge of the turf are rendered at the turf level + 0.005. Decals would be at 0.004 and below.
Objects in the center of the turf are rendered at the turf level + 0.01. Mobs would be at 0.011.
Objects at the front of the turf are rendered at the turf level + 0.015 (allowing them to obscure mobs standing behind them, but not in front of them.)
Gasses or full-tile overlay objects would be rendered above the turf level + 0.015 (between 0.015 and 0.02)

Assuming that maps are 256x256 tiles, this would mean layers 2-60 are reserved for in-game atoms, and anything above and below this is used for effects and screen overlays (like -99 for clickcatcher plane, or +61 for hud/criteffect etc.)

The only concerns i can think of that would prevent this are weird stuff like "skewium", weird layer hacky stuff i can't think of, and the potential processing overhead of having objects change layers whenever they are moved (as well as the inevitable objects and forms of movement that are overlooked when it's first changed. (IE. teleportation doesn't trigger layer-swap, doesn't get caught until after it's merged)

So can i try and do this? or will people hate me/prevent it from being merged?

Update: Lummox said that client.dir has been depreciated since 4.0.
Update: That and my dumb ass assumed that rotatium even used client.dir in the first place.
Last edited by nullbear on Wed Feb 13, 2019 4:21 am, edited 2 times in total.
User avatar
MisterPerson
Board Moderator
Joined: Tue Apr 15, 2014 4:26 pm
Byond Username: MisterPerson

Re: Icon Layering Question

Post by MisterPerson » #476077

One thing to keep in mind is that planes have "priority" over layers. Something on plane 1 layer 2 will appear above something on plane 0 layer 3. So you don't need to worry at all about stuff that's not in the game world (HUD, lighting, AO, fullscreen effects, the HUD backing, parallaxing, etc). Additionally stuff on a client's screen is always above or below stuff not on screen, so even if they shared a plane, you wouldn't have to worry about layering for that stuff either. Thus I also don't think skewium type stuff would mess it up, although obviously test it anyway because you never know with BYOND.

Look out for overlays/underlays with non-negative layers. These would obviously completely break the entire system. Thankfully they're fairly obvious and frankly aren't worth caring about. They're very rarely used and are generally mistakes anyway. In fact I wouldn't be surprised if there were literally none and even if there are, it's an easy fix. On a related note, there's probably some stuff manually setting its layer which obviously would have to be changed too.

Forget teleporting, I would be far more concerned about mobs dropping things (especially mechs), disposals shooting things out, items spawning without calling super like they're supposed to, and probably a host of other movement-related issues that'll be annoying. But totally worth it because movement code is important damnit.

Personally I would suggest reserving a huge range you want stuff to be in (probably 1-9999 just to be sure) and then starting "always over everything layers" at 10,000 or whatever. The more you work with whole numbers, the better, so as to avoid floating point imprecision as much as possible, and hey, layer is 32 bit anyway, might as well take advantage of that unnecessary size. Although I'd have to test BYOND's default layer defines because I think one of them is a really high number you obviously don't want to collide with.

Small quip: This change would reintroduce tactical chairs. I still like it though.
I code for the code project and moderate the code sections of the forums.

Feedback is dumb and it doesn't matter
User avatar
oranges
Code Maintainer
Joined: Tue Apr 15, 2014 9:16 pm
Byond Username: Optimumtact
Github Username: optimumtact
Location: #CHATSHITGETBANGED

Re: Icon Layering Question

Post by oranges » #476125

the size is hardly unnecessary is it, it's for flexibility.
nullbear
Joined: Tue Apr 26, 2016 11:32 pm
Byond Username: Nullbear

Re: Icon Layering Question

Post by nullbear » #476148

Biggest issue I see is w/ client.dir and I don't know how to tackle that gimmickry (rotatium) Honestly kinda wanna just say "fuck it" and either remove shit that fucks with client.dir, or leave it in with the bugginess.
nullbear
Joined: Tue Apr 26, 2016 11:32 pm
Byond Username: Nullbear

Re: Icon Layering Question

Post by nullbear » #476180

As far as i can tell, there's no way to get it to work with client.dir.

Byond has a map_format for "side_view" which does exactly what im trying to do. But as you can see here: https://imgur.com/a/IfVazGc it's not very compatible with ss13.

As far as I can tell though, this WOULD deal with the issue i'm having with client.dir. Update: NOPE. Makes for even MORE fuckery.

I think the most effective way to do this would be to change the map format to side-view, and figure out what isn't compatible and why. But for now, i'm chucking this in the bin.
Last edited by nullbear on Wed Feb 13, 2019 4:08 am, edited 1 time in total.
nullbear
Joined: Tue Apr 26, 2016 11:32 pm
Byond Username: Nullbear

Re: Icon Layering Question

Post by nullbear » #476191

Something i noticed though is that the "colors" list for lighting objects appears to be deleted and re-initialized every tick. Would there be any performance benefit if it were cached?

Also; Lummox posted at some point that client.dir has been depreciated since 4.0, which is why it's such a fkn ordeal to work with.
User avatar
MisterPerson
Board Moderator
Joined: Tue Apr 15, 2014 4:26 pm
Byond Username: MisterPerson

Re: Icon Layering Question

Post by MisterPerson » #476269

Yeah we shouldn't be using client.dir at all. Even if it did work correctly, it wouldn't handle overlays. Just offhand, what actually uses client.dir anyway? Rotatium? Why? It could just work like skewium.
I code for the code project and moderate the code sections of the forums.

Feedback is dumb and it doesn't matter
nullbear
Joined: Tue Apr 26, 2016 11:32 pm
Byond Username: Nullbear

Re: Icon Layering Question

Post by nullbear » #476294

nullbear wrote: Update: Lummox said that client.dir has been depreciated since 4.0.
Update: That and my dumb ass assumed that rotatium even used client.dir in the first place.
Post Reply

Who is online

Users browsing this forum: No registered users