Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[World] Partial updates for sprite vertex caches #29

Open
riperiperi opened this issue Sep 1, 2016 · 0 comments
Open

[World] Partial updates for sprite vertex caches #29

riperiperi opened this issue Sep 1, 2016 · 0 comments

Comments

@riperiperi
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant