You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when one element in a sprite group (wall/staticobj/floor) changes, the whole cache for it is regenerated, then re-rendered. This can get very expensive for viewing multiple floors, especially when one is more active than the others (eg. walls cutaway on top, all others walls up).
Sprite caches should be generated per-floor. This has obvious benefits despite needing more draw calls, and in render modes like software depth for iOS, the sprite-texture groups tend to be split over floors anyways due to their overlaps.
In fact, since baked sprite draw-arrays are only for sprites sharing the same texture, we only actually need to regenerate the them for textures where the sprites have been modified, removed or added. This requires a lot smarter sprite tracking, which should be easy to do for objects (since they have sprites hard-attached to them), but will likely require a considerable rewrite for walls/floors.
It's worth considering even just for objects alone, as they tend to have the most draw calls. For example, one object in the cache could change, but no other of the 3000 sprites share the same texture, therefore they can continue using the vertex data generated previously. This would directly impact the "dynamic" object layer the most, as it currently regenerates its sprite caches every frame.
The text was updated successfully, but these errors were encountered:
Currently, when one element in a sprite group (wall/staticobj/floor) changes, the whole cache for it is regenerated, then re-rendered. This can get very expensive for viewing multiple floors, especially when one is more active than the others (eg. walls cutaway on top, all others walls up).
Sprite caches should be generated per-floor. This has obvious benefits despite needing more draw calls, and in render modes like software depth for iOS, the sprite-texture groups tend to be split over floors anyways due to their overlaps.
In fact, since baked sprite draw-arrays are only for sprites sharing the same texture, we only actually need to regenerate the them for textures where the sprites have been modified, removed or added. This requires a lot smarter sprite tracking, which should be easy to do for objects (since they have sprites hard-attached to them), but will likely require a considerable rewrite for walls/floors.
It's worth considering even just for objects alone, as they tend to have the most draw calls. For example, one object in the cache could change, but no other of the 3000 sprites share the same texture, therefore they can continue using the vertex data generated previously. This would directly impact the "dynamic" object layer the most, as it currently regenerates its sprite caches every frame.
The text was updated successfully, but these errors were encountered: