object.z or object.drawOrder?

[kikito]

I'm modelling drawing orders in PÄSSION now.

I need to define the property that manages the drawing order.

I was going to call it z, but then I realized that people might want to use it for 3d-ish stuff. And in 3d, z doesn't define the drawing order (it depends on the viewer's position & orientation)

Then I thought about drawOrder. It is obvious (I like that) but somehow I'm not completely satisfied with it.

The CSS property for ordering stuff is called zIndex. Maybe I should use that one.

Which name do you prefer?

[kikito]

So drawOrder it is. Still think the name isn't elegant enough, but mathematically it was the best candidate I had.

PÄSSION now is able to sort actors by drawingOrder (or by anything else, really. It is now very flexible in the order in which the actors are processed)

Closing poll.

[osuf oboys]

Not a vote but some arguments... I would personally prefer "z" because many find it synonymous with "drawOrder" but you can do more with "z" than what is acceptable to call "drawOrder".

More specifically, you can specify a vector for mapping (x,y,z) to (x,y,drawOrder). A GUI, where z only affects drawOrder, merely uses the vector (0,0,1). An orthogonal tile-based game would have things like (0,1,1) and "isometric games" could be (0.5, 0.5, 1) and other alternatives. This gives a lot of power and nice effects with little hassle. It is also essentially mandatory if you want the system to be used for tile-based games and I do not see why such simple yet standard functionality should be left out. Calling a term that does this for "drawOrder" is horrendous - drawOrder is the result! You could obviously have a reader for drawOrder though as well as the option to override (offset?) the computed value.

[kikito]

Hi osuf,

I've called the property drawOrder, but the engine uses a getter/setter for it. If you subclass from Actor you can override getDrawOrder() and do whatever you want. I'm actually doing that already, on the gui.

As a rule of thumb, Actor only uses getters/setters, so everything can be redefined.

you can specify a vector for mapping (x,y,z) to (x,y,drawOrder)

I'm not very good at math and these trigonometry details tend to escape me. It sounds intriguing, but sorry I don't understand you .

I just knew that it felt "wrong" coupling the z coordinate with the drawing order; if you have a moving "camera" the things that are closest to it have to be drawn before, even when it's "looking down"... so I though - ok, this requires decoupling.

[osuf oboys]

Hmm, yes, I admit you are right. drawOrder should appear higher in the hierarchy with it overloaded on a lower level to facilitate drawing of in-world objects. My comments were more aimed at the Actor level - where having to deal with mapping x,y,z is so common place that I think, with most of the functionality, it could be there by default. It does not really hurt anything since you can set the base vectors to use z as drawOrder and ignore everything else.

See http://en.wikipedia.org/wiki/Isometric_projection for the linalg.