The current limit of 10 is limiting how many things I can stack over each other. I know that newer created items with the same ZIndex as an older one will overlap the older one, but I use ZIndex to ensure that, should this change, I am not affected.
Any chance it could be increased as my recent project requires that a number of GUI objects are overlapped?
An increase of just 2 would be good enough for me. Thanks
[quote] The current limit of 10 is limiting how many things I can stack over each other. I know that newer created items with the same ZIndex as an older one will overlap the older one, but I use ZIndex to ensure that, should this change, I am not affected.
Any chance it could be increased as my recent project requires that a number of GUI objects are overlapped?
An increase of just 2 would be good enough for me. Thanks [/quote]
I don’t really understand why there needs to be a limit.
True, it is just a comparison to sort the list to render the GUI
Why do they even need to sort it at all? Don’t we have depth buffers to do that?
Assuming it is a rudimentary system, either way, why is there a limit?
Holy crap – what are you doing that requires that many ZIndexes?
12 overlapping GUIs isn’t a huge number…
No-mo ZIndex limit, I have exceeded it making an operating system out of gui, and it was annoying, I had to make my own ordered rendering system, that would draw the guis in overlapping order 0_o
I wish there wasn’t a limit. I mean it’s just a way of sorting the layers, right? Not like there’s actually a rendered layer for each incremented index. At least I hope not. For example, the z-index for HTML elements in CSS can really be any range of numbers and it works great.
You know how ROBLOX does things. They probably don’t just compare ZIndices - they probably use a for loop or something and make like a “render-in-this-order” list from 10 to 1. I mean yeah it is a bit faster when you know exactly what your max and mins are, but there’s got to be some way to do it without knowing the max and the min. Like crazyman32 said, “CSS can be … any range of numbers”
Aren’t Z (depth) buffers only used for 3D graphics?
As far as I know, GUI elements do not use a depth buffer.
Anyways, there is no reason to have this limit. Just use er sorting algorithm to ensure the correct drawing order.
Aren’t Z (depth) buffers only used for 3D graphics?
As far as I know, GUI elements do not use a depth buffer.
Anyways, there is no reason to have this limit. Just use er sorting algorithm to ensure the correct drawing order.[/quote]
I don’t see why it cannot be applied to 2D graphics, too, just instead of the depth into the screen you use the ZIndex.
I wish the Zindex was “scoped”
Doesn’t the ZIndex only come into effect AFTER the hierarchy layering?
Example: A parent object would always be behind its children.
I remember reading about it somewhere but was it actually implemented?
[quote] Doesn’t the ZIndex only come into effect AFTER the hierarchy layering?
Example: A parent object would always be behind its children.
I remember reading about it somewhere but was it actually implemented? [/quote]
No
[quote] Doesn’t the ZIndex only come into effect AFTER the hierarchy layering?
Example: A parent object would always be behind its children.
I remember reading about it somewhere but was it actually implemented? [/quote]
No[/quote]
Something like it – you can pretty much make your own ZIndexes like 1.1, 1.2, 1.3, because the GUI objects pasted/inserted AFTER something on the same index will display above it. With this, you can pretty much have infinite indexes, even though it’s a pain.
Sorting is a really old problem in computing. Putting a limit on it make the algorithm run faster no matter what, so it’s probably an optimization to keep GUIs running lightning-quick.
#CollegeKnowledge
[quote] Sorting is a really old problem in computing. Putting a limit on it make the algorithm run faster no matter what, so it’s probably an optimization to keep GUIs running lightning-quick.
#CollegeKnowledge [/quote]
Then let’s just increase the ZIndex limit to 50. I’d be surprised if someone would develop a GUI complex enough to use all 50.
[quote] Sorting is a really old problem in computing. Putting a limit on it make the algorithm run faster no matter what, so it’s probably an optimization to keep GUIs running lightning-quick.
#CollegeKnowledge [/quote]
Would still take at least nlog(n) (n is number of elements in list to sort) time to sort regardless of size, why would a limit change that, you’re only doing number comparisons?