Icon Layering Question
Posted: Tue Feb 12, 2019 5:25 pm
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.
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.