Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - rooger

Pages: [1]
1
Hi. Thanks for the reply.

I took a look at Maik Klein's solution and i find it quite interesting. It pretty much "solves" the problem I encountered previously which prevented me from looping over more than one array of component at a time (because of the reordering and indexes that don't match anymore from one array to the other).
His solution is roughly equivalent to using X number of "entity managers" rather than just one. Each one manages its components arrays.

Anyway I implemented something similar to Maik Klein on top of my previous experiment just from reading his blog post. He's using Hana. I kept using Niebler's Meta. Also from the start I was using the C++17 folding expressions which are awesome.

Something interesting (not sure it's that interesting though lol) is I have to access tuple elements by an index at runtime in some occasion. Basically the component group ID (tuple index) is stored in my handle type as a runtime member rather than a constant template parameter. Weird design choice maybe but I wanted to have the same type for all my handles.

This is just a brain dump of what I have done. It's mostly a pretext to get back to c++14/17 programming rather than a serious project: https://github.com/metagoto/rako



2
Great talk. Thank you.

Interestingly I have an ECS implementation which is very close to yours and was developed completely independently [1]. Same emphasis on compile time configuration (C++1y FTW). The bitset with tags at the end, the components meta list and the concept of signature, everything is here. For that latter I don't request the user to declare his signatures prior using them (I use Eric Niebler's tiny meta library). Yet we both pass lambda with expanding auto& arguments matching the components. Awesome.

My tuple of vectors of components data are "compressed". Random access requires an extra level of indirection through a lookup table (handle ID+counter). Initially I thought it was a good idea which allowed me to loop through valid components data without encountering "holes" but it prevents me from looping over more than one vector at the same time because indexes don't necessarily belong to the same entity (compression might reorder slots in one vector but not the others).

Also I should definitely use std::get<T> rather than std::get<size_t> for tuple element access. It simplify things greatly ;)

[1] I'm by no mean a game developer but got interested in ECS after reading stuff about DOD. I don't remember having watched your video but I for sure read lots of articles on the net. The compile-time approach (meta list of components) without some kind of static counters or typeid doesn't seem common at all.

Pages: [1]
anything