Re: Software Architecture/Design

In Data oriented development there's a couple of problems with the way some
people seem to be reading the threads. I'll try to right a couple of
conceptual misunderstandings here.

On 6 June 2010 17:16, Megan Fox <[email protected]> wrote:

> It also isn't zero-sum, as setting variables up this way gives you a
> super way of letting script and code interact transparently wrt.
> variables... but even ignoring that, this scheme does seem perfectly
> usable, unless I'm missing something?  The extra lists would give a
> tiny bit of overhead, but that seems about it?
>

Firstly, variables in a traditional sense, they're not really a concept that
is seated well in stream processing. What you've got instead are incoming
and outgoing streams of data, or streams of data for modification. There is
no such thing as a "variable" in the traditional sense of something you can
check and modify and update if you feel like it. Think about how a GPU
operates on vertex data, it doesn't go and get some more data if it feels it
needs it, also it doesn't poke out some other data for later in case it's
necessary. The only variables you get in shader languages are local ones, or
constants. All your "variables" are large data arrays (texture buffers in my
experience).

Secondly, script wouldn't be interoperating with code, the scripts are data
too, so they will be interoperating with data. In a data oriented approach,
I so far find that nothing actually interacts with the code. The code allows
data to interact with other data, but never with itself.

I'll be interested if someone who's done data oriented development can give
me an example of where the code actually was interacted with by the data.


> (I realize another approach is to break the "entity" up into
> functional parts arranged in a list, where each component defines and
> adds its own part, but this makes interoptability nasty when part A is
> having to request part B's data chunk for use and thus has to know
> something about part B or at least defined by part B)


This is sliding back into an object oriented approach.
Interoperability between part A and part B implies that part A knows
something. Anything.
This is meant to be data oriented development, so the data knows nothing.
Part A will never request anything of part B because part A is just dumb
data. Part A has no methods, neither does part B. An operation on part A
does not request anything of part B unless that operation is for combining
the part A stream and part B stream to do some processing.
I'll try to clarify one more time, borrowing from Morten's SO/PO
descriptions

In OO, if part A calls in part B, it can happen like this:
partA->Tick()
{
 /*body*/
 if( this->SomeCondition() )
  this->GetEntity()->GetComponentB()->DoSomething();
}

in Data oriented, you can do this:
partA -> [ tick and generate B processing requests ] -> partA + partB
process requests
partB + partB process requests -> [ process partB ] -> partB

Keeping the partB process requests
this way, it's possible to use partB process requests to preload the cache
with the right partBs so that processing doesn't stall, and you don't have
the extra I cache miss of moving between scopes of doing the tick for partA
and processing of partB.

-- 
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