On Tuesday, 8 October 2013 at 05:24:13 UTC, Elvis Zhou wrote:
On Monday, 7 October 2013 at 17:06:40 UTC, Kiith-Sa wrote:
On Monday, 7 October 2013 at 15:21:00 UTC, Elvis Zhou wrote:
On Monday, 7 October 2013 at 14:19:20 UTC, Ali Çehreli wrote:
On 10/07/2013 02:18 AM, Elvis Zhou wrote:
ArtemisD:
https://github.com/elvisxzhou/artemisd
Just a little note: As it's more readable, you may want to
use 1000.msecs instead of dur!("msecs")(1000) in the example
program. 1000.msecs is the equivalent of the msecs(1000)
function call, which returns dur!("msecs")(1000).
Ali
Done, thank you!
I'm implementing pretty much the same thing in my project,
although I'm probably
more in line with the original blog post (e.g. every system
can only access
specific components of an entity, which are statically
determined, entities are more lightweight, etc.). I'm using
much less OOP and more of a generic/metaprogramming approach.
Currently I'm trying to rewrite the code to add a concept of
"past" and "future" state; a System processes past Components
and outputs a future Component, past Components are const, and
no two systems may write to the same future Component. This
should allow very simple threading
with little synchronization.
I'll look at your code if there are interesting ideas.
The previous version of my entity system is used in my ICE
game:
https://github.com/kiith-sa/ICE
It's quite messy, though; which is why I'm rewriting it.
The new version doesn't even compile at the moment, I'm
working on it slowly as I'm studying and working at the same
time right now.
I'll look over the comment and post if I have any further
feedback. The only thing I can say right now is that there is
inconsistent tab-space indentation in some parts of the code
(e.g.
https://github.com/elvisxzhou/artemisd/blob/master/source/artemisd/entity.d
)
I'll give it a try, thank you!
My main concern in the D port is, since getComponent is the
most important and most used function, often in every frame,
but caching it is not a good idea cause any component may
be removed or added at any time, with an additional
mixin TypeId in component definition, component then can be
get with its TypeId(index of component list) in zero cost.
In other ports, like Java or C#, even in C++, a ComponentMapper
like stuff is used to hash a component type to find a registered
index before you can get it efficiently.
What do you think?
In my implementation I don't even use a getComponent equivalent;
a process()
(or opApply() in the older version I linked) function directly
takes component
references, and all components are in plain arrays. Processing of
a System
is done (in generated code) by iterating over the components the
System specifies in its signature, which is cache-friendly, and
means the components needed are always available directly to the
process() function without any lookup. However, this is a less
flexible approach than what you're doing (although intentional,
again, to eventually enable very easy threading).
That said, in my code, entities can only be added/removed between
frames
(a System might create a new entity but it will only start to
exist with the next frame), and components cannot be changed once
the entity is created (although the new past/future design I'm
working on now might enable that).
