Re: sparse components

At least in my implementation of it, component orienting the processing
means that each component type is processed at a code defined moment in the
main loop of the game. I use vectors as they're faster, and iterate over
them in a processing function, not constantly calling a member method on the
iterated class. I found that this was faster and can only assume that the
instruction cache was hinted to stay warm by doing it this way.

I've moved away from classes to hold data for processing now, except in the
case of SIMD data.

On 31 May 2010 01:57, Jedd Haberstro <[email protected]> wrote:

> Can someone expand upon what it means to orient the component processing to
> a per component type rather than per entity? Is it basically changing the
> relationship between entities and components; instead of registering a
> component with an entity, the entity is registered with the component and
> added to a list of entities?
>
> ------------------------------
> *From:* Tony Albrecht <[email protected]>
>
> *To:* [email protected]
> *Sent:* Sun, May 30, 2010 7:49:21 PM
>
> *Subject:* Re: [Sweng-Gamedev] sparse components
>
> On 29 May 2010 00:14, Richard Fabian <[email protected]> wrote:
>
>> In my component system, I oriented the component processing to a per
>> component type rather than per entity, which meant I was keeping the I cache
>> warm all the time.
>>
>
> This is how I've always thought component systems worked and was their main
> benefit
>
>
>> I was lucky, I hadn't noticed this benefit at the time, and now I do.
>> Also, because components only existed for entities which needed them, there
>> was no processing done for entities without that component.
>>
>
> Its an awesome benefit - like you said your cache is warm and it lends
> itself very well to parallel processing. Dependencies are far more obvious
> than in traditional entity based processing. (Note how I avoided mentioning
> OOP for fear of dragging this thread even further off topic)
>
>
>> So, what's this stuff called normally, and also, why aren't we taught
>> anything about it, and why aren't we using it?
>>
>> I don't know what its called, but I think the main reason that its not
> being used is because it hasn't been used much. Most programmers aren't
> familiar with it and would prefer to continue with their old thought
> processes - especially when time and budget are tight.
>
>
>> I've seen speed ups in my own code due to rewriting small sections in this
>> style, so can't fathom why we're not using it in general, or for that
>> matter, taught it at all.
>>
>
> I think all it will take is a few people to actually write games using this
> type of (dare I say it) pattern and to share the benefits of it for it to be
> adapted by more people. Up until recently the benefits of component based
> programming weren't really evident, but with our painfully slow cache misses
> and multiple core systems, the benefits are really starting to outweigh the
> negative (mainly lack of familiarity).
>
>
>>
>> I've breathed even more life into this technique with my current work on
>> writing up my experience with data oriented development by adding or at
>> least clarifying what this sparse existence component technique can offer,
>>
>
> I applaud this type of work and look forward to reading what you find.
>
>
>>
>> I'm currently doing general research to find out if there are other old
>> science techniques that we've forgotten, or not repurposed, while also
>> writing a proof of concept rogue-like in 3D. This does mean I have to write
>> two whole games that are exactly the same, as best I can, just to prove any
>> of my research, but I hope that doing so I may come across some other
>> unexpected discoveries.
>>
>>
> Writing two games, while painful, is the best way for people to really
> appreciate the benefits of your component technique. It provides an easy way
> for people to contract performance, memory use and usability - although
> you'll find that many will still miss the point completely and start arguing
> about OOP.
>
> One of the reasons I think that component based architectures haven't
> really taken off is that they only really start to benefit once your systems
> scale up significantly. For example, dealing with 100s or 1,000s of object
> rather than 10s. What interests me is what is the pivot point at which
> component is better performing than an entity based system? Take your
> rogue-like for example; Are you really better off treating health
> regeneration as a separate component and incrementing all live health
> components at once, or since the health regen is such a trivial calculation,
> should that be rolled in with something else? Where do you draw the line?
>
> I honestly think that as people see more well written component systems
> that work well on current HW and scale well onto multiple cores, we'll see
> more and more component based solutions. From what I remember, Pandemic used
> a simple, high level component based system on PS2 for Destroy All Aliens 2
> (and possibly 1) and Mercenaries 2 on PS3 and X360 used a much lower level
> component based system. I wasn't closely involved in those projects so I
> can't really provide an info on the pros and cons of those implementations.
>
> -Tony
>
>
> _______________________________________________
> Sweng-Gamedev mailing list
> [email protected]
> http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
>
>


-- 
fabs();
Just because the world is full of people that think just like you, doesn't
mean the other ones can't be right.

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com