.NET Standard roguelike library in C#. Features many algorithms and data structures pertinent to roguelike/2D game developers, specifically designed to be minimally intrusive upon the developer's architecture.
MIT License
494
stars
31
forks
source link
WalkabilityView and TransparencyView Could Support Caching Model as an Option #293
Currently, GameFramework.Map's WalkabilityView and TransparencyView proeprties are custom grid views which, in the case that entity layers are part of the appropriate layer mask, effectively call spatial map functions to iterate over all entities at a location and check to see if they are walkable.
This is fairly simple, and not completely inefficient since spatial maps are relatively fast; however, it represents a tradeoff of memory vs performance for the user. No syncing with the actual entities, or caching, is necessary, because when somebody using the grid view queries the values, the spatial map functions are called on the spot; and as such, very little memory is taken up by these grid views. However, the performance is very likely to be less than what could be achieved if the values were a cached ArrayView or BitArrayView which was updated when items were added/removed/moved/had properties changed.
Particularly since BitArrayView is now implemented, this tradeoff is not always the sensible one; a BitArrayView takes up only 7kb of space for a 250x250 map; 14kb of memory (for both a BitArrayView for transparency and walkability) for a significant speedup is certainly a valuable tradeoff in some, if not many, circumstances.
At minimum, Map should offer the user some form of customization of the method by which these grid views are tracked; whether that's a flag or just some enum stating a method.
It also may be a good idea to consider changing the default to cached maps, depending on how the performance tests turn out.
Chris3606
commented
1 year ago
Currently,
GameFramework.Map'sWalkabilityViewandTransparencyViewproeprties are custom grid views which, in the case that entity layers are part of the appropriate layer mask, effectively call spatial map functions to iterate over all entities at a location and check to see if they are walkable.This is fairly simple, and not completely inefficient since spatial maps are relatively fast; however, it represents a tradeoff of memory vs performance for the user. No syncing with the actual entities, or caching, is necessary, because when somebody using the grid view queries the values, the spatial map functions are called on the spot; and as such, very little memory is taken up by these grid views. However, the performance is very likely to be less than what could be achieved if the values were a cached
ArrayVieworBitArrayViewwhich was updated when items were added/removed/moved/had properties changed.Particularly since
BitArrayViewis now implemented, this tradeoff is not always the sensible one; aBitArrayViewtakes up only 7kb of space for a 250x250 map; 14kb of memory (for both aBitArrayViewfor transparency and walkability) for a significant speedup is certainly a valuable tradeoff in some, if not many, circumstances.At minimum,
Mapshould offer the user some form of customization of the method by which these grid views are tracked; whether that's a flag or just some enum stating a method.It also may be a good idea to consider changing the default to cached maps, depending on how the performance tests turn out.