The need for this discussion is stemming from implementing animations. When sprites in an animation overlap, one obviously has to be drawn over the other. The determination of which gets this precedence is the issue.
From a user’s point of view, it’s pretty simple: have an option to “bring to front” for individual sprites after they’re placed. Or have a Z index that you can manually set. From an engine point of view, those rules have to be obeyed for any number of animations simultaneously, each of which can overlap each other as a group.
A potential solution to this involves giving a strict z index to each sprite in an animation, even if this doesn’t end up being something the user specifies. However, there’s already z indexing in place to control visibility of anything rendered. This was primarily done with individual rendered rectangles in mind. (Showimg, basically.) Throwing in groups of images (animations) that have their own sub-z-ordering in place isn’t a simple task.
Anyway… to the actual question, if all of that hasn’t just completely confused anyone. How many layers do you feel the engine needs to have available? These layers are separate from tile layers, but do interact with tile layers in the sense that you’ll need to use values under a tile layer’s z value to render under that tile layer. This would be the number of layers available to explicitly control the ordering of rendered images, animations, particles, or whatever. Graal basically does this with “changeimgvis”, but that also controls the coordinate system used. Coordinate systems will be separately handled in this engine.
For example, changeimgvis index,4; in Graal would render the image above everything in a level, and use screen coordinates. But I don’t believe there was any extra means to control the z order within that “layer”. I think this caused me some headaches on multiple occasions. This engine will provide a means to be more specific, but I’m curious as to how much depth is really needed.
One additional thing to note is that anything rendered on the same layer will have an undefined display order. Something a script displays one time you have the client open might appear differently the next time you have the client open, or even within reentry into a level, when rendering in the same layer with overlapping pixels. This is why it becomes important, if the ordering matters for whatever you’re doing, to have things on separate layers. I believe this is also true with Graal, but I can’t specifically recall having seen it occur.
If I am reading this correctly then you’re talking about having subset of layers so something drawn on layer 1 and then ordering other draws on the same layer? If that’s the case, something just automated and reproducible is good in my opinion. Just the normal last one drawn is drawn on top…
“Last one drawn” isn’t an option unless I want to drop overall performance by roughly 500%. That’s why there’s a need to be explicit about how this behaves. If you NEED something to draw over something else, it MUST be on a higher layer. The question is… how many layers does everyone foresee the need for?
The order in which they’re drawn isn’t the issue in this case. I COULD use a system that was entirely dependent on draw order, but see my 500% performance reduction comment above. This is primarily because texture switches are expensive operations. So you can’t chaotically render without regard to what texture is being used to draw. (In 3D hardware, a texture is an image.)
Since layers are using hardware z ordering, there is an imposed limit, and not even by myself. I don’t have a precise maximum that the hardware can handle, but I’m going with a maximum of 500,000. The UI will have its own separate limit of that same amount. In order for animations to work as expected, they’ll need to have some separate maximum set for them… let’s say 1000 layers. That means each layer must be offset by 1000 in order to account for the space needed by any animations on that layer. The end result is that the number of usable layers is divided by 1000. So with that 500,000 maximum, you’re reduced to 500 usable layers. This would also mean that animations could only have a maximum of 1000 layers within each one. Once that limit is reached, the “on top” aspect of each sprite would be undefined.
So the need here is to come up with a compromise between maximum layers in an animation and maximum layers in the client as a whole.
I get the idea that no matter how many layers you define, there’ll be at least a few situations where this becomes an annoying restriction, especially in the case of something like a snake.
If you were to take a typical player animation, I’d say the amount of layers you’d need is shoes + plants + shirt + head + hat = 5, so if you were to double that (10) you’d be well covered for the majority of cases.
Could you elaborate on the snake thing? I’m not entirely sure what you’re referring to.
Keep in mind that I don’t want the engine limited to Graal-like parameters. Someone may want to do something with more complexity than a typical Graal character.
Performance won’t be impacted by the allocation of layers.
Each rendered image doesn’t necessarily have to take up a separate layer. They can share layers. It’s entirely up to the developer. In the case of two images that will never overlap, that’s an example of where you could share a layer with no detriment. Sometimes you may even have overlaps that you don’t care about the order of.
So say I had a sprite sheet where I have a tail, one body segment and a head for a snake. Then I wanted the body segment to always be drawn before the following segments, so the longer the snake, the more layers required. I admit it’s a somewhat ridiculous case but I think you get the point when compared to what graal does currently.
Also how is layering of animations considered when tied into level layers. If you have 500 usable layers. Say for example you have an animation with 300 layers (yes, ridiculous). Then you have a npc using that animation on tile layer 1, and another npc using the same animation of tile layer 3 so there would be 600 animation layers alone right? The point of this example is just to understand how animation layers and level layers play together.
That’s kind of funny somehow. But yes, currently that would be correct. For sprites rendered from the same image, it may be possible for me to guarantee layering based on draw order, but not for different images.
No. Each “level” layer has its own subset of 1000 (if that’s what I go with) animation layers available to it. Additionally, multiple animations could share a layer, but their sprites that share animation layers would be drawn in an undefined order:
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“data-attachmentid”:189702}[/ATTACH]
Animation sprites in layers 1000 through 1003, if any have overlapping pixels between the two animations, would have an undefined order of drawing.
Oh, I forgot to mention… the animation layering would be transparent to the user. While internally they’d use z-values as shown in the illustrations I’ve posted, from a scripter’s point of view, you’d see layers 1-4 using values 0 through 3. Inside the animations, you’d see values 0 through 999. The translation to the 0 through 499,999 would happen within the engine itself. So it’s not as complex for users as it sounds.
No, two layers. Animations would be, from your point of view and layering, looked at as a single sprite. The engine would handle the internal layering of the animation.
Haha, I was thinking the exact opposite. I don’t think animations generally have a huge number of layers individually, but the world, on the other hand, has many NPCs and animations at once.
I hope it doesn’t seem like I’m ignoring everything posted. The questions and comments do help me to decide, which is what the point of this is anyway. I’m hoping to have rendering of these ready to show before I go to sleep tonight.