Closed LPGhatguy closed 3 months ago
Refactoring of QueryBorrow to enable random access
This would involve taking the fetch
field of View
, which is a table with one entry per archetype, and adding it to query
, populating it either up front (which adds unnecessary work to normal queries) or lazily (which adds a branch to every random access, the case that views are specifically supposed to optimize). Given those (minor) drawbacks, I think I lean slightly towards paying the modest one-time cost of introducing a new type (perhaps ViewBorrow
).
Are you interested in making a PR for this?
I'd be interested in working on this feature, but I'm pretty booked for a couple months. If no one else comes along and takes it by then, I can take a look!
I created a cursed and unsafe version of this API in the hecs wrapper we have in our engine. We use views a lot, so I think it will be very nice to have.
I'm going to use it for awhile and see whether it's a very large gain. If it is, I'll take a go at implementing it properly in hecs!
This would incrementally tidy up some of the code I've been writing lately too.
Fixed by #367.
hecs has a great mechanism for random access of a query via views:
It'd be really handy to collapse the calls to
query
andview
into just one call, to avoid needing to create the extra binding.I think there are a couple good solutions to this problem:
World::view
and a newView
type that owns its contentsQueryBorrow
to enable random access