Kiith-Sa Posted in reply to Kiith-Sa



Permalink Reply

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 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 On 10/07/2013 02:18 AM, Elvis Zhou wrote: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! On Monday, 7 October 2013 at 14:19:20 UTC, Ali Çehreli wrote: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. On Monday, 7 October 2013 at 15:21:00 UTC, Elvis Zhou wrote:I'm implementing pretty much the same thing in my project, although I'm probablymore in line with the original blog post (e.g. every system can only accessspecific 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 threadingwith 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: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