Creating a view from elements with respect to their assigned type id

[batuhanbozyel]

I am trying to iterate over a view of components where their storage has a unique assigned ID from my custom reflection system. Is there a built-in functionality to achieve this? If not, how to implement one myself, here is my simple abstraction to iterate set of components without using the reflection system's type id:

template<typename ... ComponentTypes, typename ... ExcludeComponents, typename Func, typename = std::enable_if_t<sizeof...(ComponentTypes) + sizeof...(ExcludeComponents) != 0>>
void ForEach(Func&& fn, Exclude<ExcludeComponents...> = Exclude<ExcludeComponents...>{})
{
    mRegistry.view<ComponentTypes..., ExcludeComponents...>().each(fn);
}

template<typename ... ComponentTypes, typename ... ExcludeComponents, typename Func, typename = std::enable_if_t<sizeof...(ComponentTypes) + sizeof...(ExcludeComponents) != 0>>
void ForEach(Func&& fn, Exclude<ExcludeComponents...> = Exclude<ExcludeComponents...>{}) const
{
    mRegistry.view<ComponentTypes..., ExcludeComponents...>().each(fn);
}

and here is an example where i use the reflection system's type id:

template<typename T, typename ... Args>
T& AddComponent(EntityHandle entity, Args&&... args)
{
	GLEAM_ASSERT(!HasComponent<T>(entity), "Entity already has the component!");
	if constexpr (Reflection::Traits::IsReflected<T>::value)
	{
		const auto& classDesc = Reflection::GetClass<T>();
		return mRegistry.storage<T>(classDesc.TypeHash()).emplace(entity, std::forward<Args>(args)...);
	}
	else
	{
		return mRegistry.emplace<T>(entity, std::forward<Args>(args)...);
	}
}

[batuhanbozyel]

This is my initial approach to this problem, having an overload for registry::view that takes in index sequence should do the job for me:

template<typename ... ComponentTypes>
auto CreateView()
{
	return CreateViewImpl<ComponentTypes...>(std::make_index_sequence<sizeof...(ComponentTypes)>{});
}

template<typename ... ComponentTypes>
auto CreateView() const
{
	return CreateViewImpl<ComponentTypes...>(std::make_index_sequence<sizeof...(ComponentTypes)>{});
}

template<typename ... ComponentTypes, size_t... Is>
auto CreateViewImpl(std::index_sequence<Is...>)
{
	return mRegistry.view<ComponentTypes...>(GetStorageId<ComponentTypes>()...);
}

template<typename ... ComponentTypes, size_t... Is>
auto CreateViewImpl(std::index_sequence<Is...>) const
{
	return mRegistry.view<ComponentTypes...>(GetStorageId<ComponentTypes>()...);
}

template<typename T>
auto GetStorageId() const
{
	if constexpr (Reflection::Traits::IsReflected<T>::value)
	{
		const auto& classDesc = Reflection::GetClass<T>();
		return classDesc.TypeHash();
	}
	else
	{
		return entt::type_id<T>().hash();
	}
}

[skypjack]

I am trying to iterate over a view of components where their storage has a unique assigned ID from my custom reflection system. Is there a built-in functionality to achieve this?

I must admit that I don't get exactly what you are trying to do/achieve. Sorry. Do you want to construct a view at runtime without providing the types at compile-time? Can you be more specific on the what I want rather than what I tried? Thanks. 🙏

[batuhanbozyel]

Sorry for the delay. No, I want the same behaviour and API to create views except that instead of using entt::type_hash for retrieving underlying storage, i want it to use my own reflection system's type hash. I will provide types in compile time but type hashes are provided in the runtime but i guess we can agree that a runtime version should do the job for me, where it takes only the type hashes for storages

[skypjack]

I want the same behaviour and API to create views except that instead of using entt::type_hash for retrieving underlying storage, i want it to use my own reflection system's type hash

Well, you have a few options here. One it to attach the EnTT hash to your meta types and use it anyway. Otherwise, you can override the way EnTT generate hashes, as long as you can define them at compile time. In this case, you can use your own and EnTT won't complain. This is a fully customizable part in the library actually. The idea is exactly to make it easy to bridge EnTT with other existing libraries that aren't part of this repo. 👍

[skypjack]

Side note: turning this into a discussion, since technically speaking it's not an issue.