增加选项控制是否禁用rearrange

[dpull]

增加选项控制, 可以让业务更灵活的控制是否rearrange

举个例子, 在后台应用时, 可能不需要rearrange, 可以基于非rearrange用法做一些优化.

[cloudwu]

你不能关了这个。否则 id 回绕后就可能和已有的 ID 冲突。

[cloudwu]

如果你需要一个不变的有序 id , 给每个 entity 自己加一个自增的 64bit id 的 component 就可以了。
你可以另外写一个 c api 二分查找到它。

[dpull]

这个pr只是增加了选项, 进行控制每次Update时, rearrange是否生效, 并没有关掉这个功能, 只是给予了lua侧选择调用的机会.

默认是启用rearrange的, 选择关闭的人, 必然对整个系统有着合理的预估.

[cloudwu]

如果你觉得不需要 rearrange 那么它实际上也不会触发。如果你觉得有可能触发，那么不调用就有 bug 。换句话说，当 max id 足够大时，不调用 rearrange 是错误的行为。

[dpull]

所以我的思路是这个事情交给lua去控制, 而非自动控制

那我们有没有一种办法既增加lua侧的灵活性(对API行为是可控的), 又保证正确性呢?

[cloudwu]

你改成 64bit id 就可以了。32bit id 有重用的可能。如果你想把 id 拿出来做 handle 弱引用，重用就是不可靠的。

因为当一个 id 被重用，只要你的系统里曾经记录过这个 id , 就无法区分指的是老的还是新的。

所以这个库目前不提供让你取出该 id 的 api 。

[dpull]

我认可ID回绕是问题, 不能隐藏这个问题.

我想解决的问题是这个功能是“自动化”的(当他执行后, 外部系统无法知晓)

我想好的API, 即应当简单易用, 又应当能提供一些可选项, 让外部更精准的操控

如果依循这个思路, 我认为这个pr也是不够的, 应当是把update函数放在lua中实现, c提供两个基础函数, _remove_entity和_rearrange, 如果你认可这个方向, 我去重新pr

[cloudwu]

这里的问题是：id 目前的实现是黑盒，完全不暴露出去的。所以外部不需要知道发生了 rearrange, 也不应该尝试控制它。说不定以后的修改内部数据结构就没有这一系列操作了。

[dpull]

你说的对，一旦开了这个口子，未来的走势就不可控了

[cloudwu]

我计划增加一个内置的 64bits id 去掉 index 模块，改成直接用 id 索引。

可能就不再需要访问这个用来相互索引用的内部 id 了。

[cloudwu]

今天我已经做了一半。增加了内置的 _eid 组件。它是只读的自增 uint64 。接下来会把 index 模块去掉，增加通过 eid 控制 entity 的方法。

变更在 v2 分支上。

我已经改变了 rearrange 策略，现在每次 update 都可能重新调整内部的 index 值，它会尽可能的重用。

现在最大的 entity 数量限制在了 24bit , 也就是 16M 。预计是够用的。这样也可以把 index 压缩到 3 字节。

有部分 api 待调整，支持传入 eid 。

[dpull]

我想调整index的原因是当index的id不存在的时候, 他的查找效率很低.(比如说index是玩家的uid, 要判断下该玩家是否存在entity)

不知道新的index模块可否能在这方面有所提升

[cloudwu]

新的是恒定的 log n 。我已经增加了 world:access 读写 component by eid 。
不过暂时还没加检测 eid 是否存在的 api 。

目前不存在抛 error

[cloudwu]

见 301446c

[cloudwu]

我已经把重构过的版本合并到了 master 。旧版本不打算维护，所以没有开分支，但留了一个叫 v1 的 tag 方便找回。

[dpull]

赞