Hey Dr. S, thanks for replying!
This is because regions have nothing to do with rects. A region is a collection of map cells. A region has a function which will select map cells to approximate the area covered by a rect at the time of function call.
Very cool, I didn't know that! So Bliz decided that, when it came to groups of rects, they needed to prioritize performance on specific operations much higher than the fact that this was the only vanilla abstraction to group rects and perform common operations on them as a group. They gained a significant optimization for scan heavy events on regions, like enters/exits region, but lost a lot of functionality that you'd otherwise expect/want from a rect collection abstraction. Do you think that's sorta the thought process?
I wonder if we could have started with a simpler rect collection abstraction and then calculated/cached its approx cell map off of the collection changing, and used that cache for quick approximations. The achilles heel here is that an individual rect within the collection could change (say resize) and there's no way short of scanning to be informed of that change - meaning the region approx cell cache would be inaccurate at that point. Otherwise, the idea keeps the performance, potentially gets the rest of the API, but loses on overhead. What do you think of their/this approach? Do you think that Bliz has the ability to easily track variable changes
under the hood? I'm very naive when it comes to game engines
Sounds like you want a list of rects? A set of rects might also work for you if you do not want duplicate entries.
Yes... but I'll take any choice so long as I don't need to make it. The most interested I've been in this topic is your reply in the above quote
A table might not be optimum for this style of operation. It is my understanding that tables generally are designed to map a value to another value. This does not imply they have list support.
I was thinking tables because my current needs for the lib care more about overhead and less about API performance. A lot of code in the List lib I linked could be simplified using Table's API following a pattern/constraints, and many of the globals would come from Table as well. Also, if I had to make it, I didn't want to deal with some of the hurdles I'd get using a rect array as the collection's core. Really, though, I shouldn't have even brought up refactoring
List. I think I should just use the best solution as-is, tuning whatever configuration it offers
Lua native tables implement list support using mappings with special layout constraints as well as providing some functions to manipulate such tables that follow the constraints. If Bribe implemented a similar system I do not know and you would have to check the API.
It doesn't, I'd do exactly this