Iterate rects

[Serenity09]

I'm running into a wall with regions creating copies of rects rather than references to the original rect itself. I need a library that lets me group collections of rects together, iterate those collections, and ideally remove rects relying on the vanilla equality comparison for rects/widgets. it would also be nice if it used Bribe's table as its core

Does something like this already exist? I found List, which is what I think i'll use if there's nothing better, with just the rect macro enabled. Maybe ill adapt it to use Bribe's table instead...

 

[Dr Super Good]

I'm running into a wall with regions creating copies of rects rather than references to the original rect itself.

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.

I need a library that lets me group collections of rects together, iterate those collections, and ideally remove rects relying on the vanilla equality comparison for rects/widgets.

Sounds like you want a list of rects? A set of rects might also work for you if you do not want duplicate entries.

Does something like this already exist? I found List, which is what I think i'll use if there's nothing better, with just the rect macro enabled. Maybe ill adapt it to use Bribe's table instead...

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.

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.

 

[Serenity09]

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

 

[Dr Super Good]

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?

Regions hook into the same data structures used by the path finder as well as other implementation details. This is why having too many cells in regions will cause the path finder to break, badly. For example units will start to walk into walls or fail to see obvious paths as well as acting overall stupid.

A rect on the other hand is literally 4 values representing a rectangular area of the map. It does not interface with the game directly and unit searches involving rects likely work by fetching units approximately within the rect extents from internal data structures, e.g. quad-trees, and then testing the actual extents.

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

Yes one could implement them differently. Look at StarCraft II where regions can be circular, square and made out of many such shapes and even anti-shapes. That likely also uses positional data structures for performance.

In Warcraft III they seem to heavily use the concept of "cell". Without seeing the source code I cannot guess why or even the advantages of such an approach. As the game is from early 2000s I would imagine it may have to do with memory constraints either bandwidth wise or amount.

 

[Serenity09]

Yes one could implement them differently. Look at StarCraft II where regions can be circular, square and made out of many such shapes and even anti-shapes. That likely also uses positional data structures for performance.

In Warcraft III they seem to heavily use the concept of "cell". Without seeing the source code I cannot guess why or even the advantages of such an approach. As the game is from early 2000s I would imagine it may have to do with memory constraints either bandwidth wise or amount.

sc2's implementation of path finding, position, and displacement is in my top 3 of implementations i'd love to hear about