Bad Component ID

[delaneyj]

Test at https://github.com/delaneyj/bar

Added more than 64 components... You'll notice that

type ComponentMapping [3]uint64

Seems right but the ids overflow.

const AZID ComponentID = 9007199254740992

const BAID ComponentID = 18014398509481984

const BBID ComponentID = 36028797018963968

const BCID ComponentID = 72057594037927936

const BDID ComponentID = 144115188075855872

const BEID ComponentID = 288230376151711744

const BFID ComponentID = 576460752303423488

const BGID ComponentID = 1152921504606846976

const BHID ComponentID = 2305843009213693952

const BIID ComponentID = 4611686018427387904

const BJID ComponentID = -9223372036854775808

const BKID ComponentID = 0

const BLID ComponentID = 0

const BMID ComponentID = 0

const BNID ComponentID = 0

const BOID ComponentID = 0

const BPID ComponentID = 0

Love the idea of this project and have some suggestions if you are pursuing it further

[zdandoh]

Thanks for cutting these issues, this is awesome feedback and these are all great findings. I'd definitely like to hear any other suggestions you have! I've gone ahead and added you as a collaborator on this repo if you'd like to make the changes you outlined, otherwise I'll get them implemented sometime this week.

[delaneyj]

I think the generation idea can be VERY powerful but right now arche is orders of magnitude faster. I think there are approaches that could rival it without the need for archetype graphs but not sure how much you are interested in the topic compared to a fun test.

[zdandoh]

I'm definitely interested to hear ideas. I can think of some simple optimizations that could probably make this library 10x faster in a benchmark like https://github.com/mlange-42/arche?tab=readme-ov-file#benchmarks but I don't think they'd hold up to real world usage.

[zdandoh]

Fixed the bug in the issue

[delaneyj]

Works