To be fair, I was pilfering loanwords like "screen-space"(adj) from the 3D dialect.
> In order to simulate a camera looking into a 3D world, I need to draw everything from the top of the screen to the bottom
Right, the point I was trying to make was that, technically, you need to draw things from the north edge of the world to the south. If you have a asset with height, you need to draw it at a higher screen position, but also a later time, than a low/short asset that's at norther world position but lower screen position. (Presumably you know that already; I was mostly asking/objecting about confusing the screen position versus the world position.)
> I can add the asset's world height multiplied by asset's (rectangle) height to the screen.y position (again, just for the depth sorting part)
My point was that you'd add[0] the world height plus the world.y position, in order to get the screen.y, but depth sort based only on world.y, independently of height or screen position. That way things that are vertically on top of each other have the same world x and y coordinates (differing only in z), even though they're draw at different screen.y coordinates to provide isometric simulation of height.
0: give or take factors of -1 depending on which way the various coordinate axes go
To be fair, I was pilfering loanwords like "screen-space"(adj) from the 3D dialect.
> In order to simulate a camera looking into a 3D world, I need to draw everything from the top of the screen to the bottom
Right, the point I was trying to make was that, technically, you need to draw things from the north edge of the world to the south. If you have a asset with height, you need to draw it at a higher screen position, but also a later time, than a low/short asset that's at norther world position but lower screen position. (Presumably you know that already; I was mostly asking/objecting about confusing the screen position versus the world position.)
> I can add the asset's world height multiplied by asset's (rectangle) height to the screen.y position (again, just for the depth sorting part)
My point was that you'd add[0] the world height plus the world.y position, in order to get the screen.y, but depth sort based only on world.y, independently of height or screen position. That way things that are vertically on top of each other have the same world x and y coordinates (differing only in z), even though they're draw at different screen.y coordinates to provide isometric simulation of height.
0: give or take factors of -1 depending on which way the various coordinate axes go