Accessing views in one specific component's order

[cmartel]

I'm in the process of working on a core set of entities to our game, where we expect to have enough processing to do to require time slicing, async processing and general scheduling work. One of the approaches I'm investigating (which may or may not be optimal) is having a scheduling processor assign a priority component to these entities, and then sorting using that priority component. Then, in theory, I should be able to time slice work by just processing entities in that priority order and stopping once the time slice has lapsed. But while there's a decent amount of documentation on how to sort components, entities or groups, there's not much in the way of accessing based on that order.

One thing I've found is that if I just use the priority component as one component of my view, even if it's the "first" in the declaration, it won't be guaranteed to be in that order:

for (auto&& [E, P, In, Out] : Registry.view<const Priority, const DataIn, DataOut>().each())

This makes sense, because the multi-component view doesn't necessarily care or respect order. I believe this could be addressed by making a group including Priority, DataIn and DataOut, but DataIn/DataOut likely will end up with different group requirements as scheduling, so I don't want to lock them into a group at this time.

Instead, it seems like my best bet is to access priority using a single component view, and then fetch the data components independently:

for (auto&& [E, P] : Registry.view<const Priority>().each())
{
    const auto& In = Registry.get<const DataIn>(E);
    auto& Out = Registry.get<DataOut>(E);
}

I'm aware that ordering being different on Priority and Data means that the order in which Data is accessed might not be the most optimal, but Data here is large enough that I'm more concerned about accessing DataIn and DataOut coherently (i.e.: potentially put them in a group, without Priority) rather than pay the cost of sorting DataIn/DataOut.

I'm just looking for a sanity check here, this seems like the "correct" way to go about this?

edit: One reason I'm not super fond of this approach is that I have multiple read/write phases over Data that are run in different processors, and I need to filter them based on "tag" components:

for (auto&& [E, P, In, Out] : Registry.view<const Priority, const DataIn, DataOut, IsDataReady>().each())

Maintaining order in the single-component iteration requires explicitly testing for the tag:

for (auto&& [E, P] : Registry.view<const Priority>().each())
{
    if (!Registry.all_of<IsDataReady>(E))
        continue;
    const auto& In = Registry.get<const DataIn>(E);
    auto& Out = Registry.get<DataOut>(E);
}

While I'm fairly certain this is essentially what happens behind the scenes anyway in a multiple component view, it just feels... clumsy spelling it out this way vs. having it be an implicit part of the view.

[skypjack]

I think what you're looking for is the use<T> function of the view class:

auto priority_view = Registry.view<const Priority, const DataIn, DataOut>().use<priority>(); // use<T> returns a new view
for (auto [E, P, In, Out] : priority_view.each()) { ... }

In this case, entities and components are returned with the order of the Priority component.

[cmartel]

Mild curiosity: from my cursory understanding of what .use() does (return a new view with the same filter, but a different pool), I don't see why it couldn't support reverse iterators? For that matter, it seems like multi-component views in general also could have reverse iterators... Just not random random access iterators, which understandably are only possible for single type views.

Unless the implicit list encoded into entity IDs is being used for iteration, but I thought that was specific to deleted/recycled entities...

[skypjack]

Reverse iterators are mainly possible when your iterator type falls into the bidirectional category.
In this case, the reverse iterator is usually defined as std::reverse_iterator<iterator_type>. This is what the standard library does after all.

Originally, multi type views iterators were designed as bidirectional iterators. Moreover, views have also had reverse iterators for a while. However, they were custom types rather than a plain specialization of std::reverse_iterator.
Was it a problem? Yes and no, it's more a matter of expectation.

When you've a bidirectional (or random access) iterator and want to create a reverse iterator, it's pretty common to invoke std::make_reverse_iterator. Especially if you don't have the container at hand. As a C++ dev, I would expect it to work properly.
Unfortunately, this wasn't the case and it caused some troubles (even to me and I'm supposed to know this library).
So, the first step was to downgrade the iterators of these views to forward iterators, so that std::make_reverse_iterator wouldn't accept them either. At that point I could have left the reverse iterators in place, you're right. However, I can't explain it but it seemed strange to me to have a container with forward iterators but also custom reverse iterators. It's neither common nor expected in general.
I mean, if you're a let's say forward container I don't expect to be able to iterate you in reverse order. So, well, as I think they were one of the least used things in the whole library, I got rid of them and that's it.
However, nothing prevents them from being reintroduced with the above limits, I agree.

[cmartel]

I had noticed the release notes saying reverse iteration had been removed, this is a great explanation of why, thank you. That all makes sense. I've mainly used reverse iterators in the context of .rbegin() and .rend(), without really thinking about the C++ convention scaffolding that functionality...

In any event, I believe it's still possible to manually reproduce the behaviour of a reverse iterator by choosing a single type view to iterate from (in my case, the sorted component) and directly filtering + accessing the other components that would be part of the view? There isn't much point in reverse iteration unless you specifically pick a component where you know ordering matters, the rest of the time the default case of picking the smallest component pool is going to yield a smaller iteration count, which would be the desired behaviour in 99.9% of cases. So if anything, requiring users to spell out the behaviour if they want it doesn't seem unreasonable (even if the .use() syntax is so very convenient!).

In my particular case, it turns out that due to the large amount of components being iterated, working backwards from the end of the ordered pool and filtering "active" components is far inferior to just filtering by "active" components and disregarding order. I'm not exactly surprised by that outcome, but EnTT makes it easy to test and compare those hypotheses, so great work! :)

[KyrietS]

Thank you @cmartel for asking your question here! 🤗 ❤️
I was about to do the same thing. I have been searching for hours for a solution to the same exact problem. I've read the entire EnTT's Wiki. Finally I googled a phrase "EnTT how to sort multi type view" and your question appeared.

My issue was something like this:

Registry.sort<Transform>([](const auto& lhs, const auto& ths) { return lhs.z < rhs.z; } // sort by Z-axis
auto view = Registry.view<Transform, Sprite>().use<Transform>(); // I didn't know about .use()!
for (auto [entity, transform, sprite] : view)
{
    RenderSprite(transform, sprite); // entities with lower z-coord are rendered first (below) entities with greater z-coord.
}

It would be clearer to me if use() function was named order_by() because that's what this function is probably used for. I'm also suprised that sorting multi type views is not covered in wiki. I would edit the Crashcourse on wiki myself and mention this function but unfortunately only the repo owner can edit wiki pages 😕

[skypjack]

I would edit the Crashcourse on wiki myself and mention this function but unfortunately only the repo owner can edit wiki pages

Wiki pages are just md files into the project. See docs/md. So, well, if you want to contribute, here we go I guess. 🙂
I am about to leave for a few days of vacation but I'm more than happy to look at a PR in this regard in the meantime. 👍
As for the name, technically speaking use isn't only about the order of iteration and therefore I decided to use a more generic name.