Re: Software Architecture/Design

Megan Fox <[email protected]>
Newsgroups gmane.games.devel.sweng
Message-ID <[email protected]>
> I'd be scared that this would suffer the same problems as C++ virtual
> populated code. Even though you think you're stream processing, you're not,
> you're processing a stream of heterogeneous data, using different
> instruction sets for each "keyword" you come across. If you replace your
> keyword with the vtable pointer, you're basically going back to the old and
> quite I cache unfriendly way of approaching this stuff.
>
> In my opinioon, stream processing is not about processing streams with on
> demand instruction mapping, it's about processing streams, with unified
> functions, but producing control flow in other ways. The existence based
> processing approach handles all your problems of virtual table style
> polymorphism. You don't need to do a per element "what's my type, lookup the
> code" process. If you do, you've broken a major point of putting your
> components in their own containers.

This would be true if you stored all the variables, regardless of
type, within the same list, but is not true if you separate the lists
by type.  That is, if you have specific Set/GetString,  Set/GetFloat,
etc operations each operating on their own hashes.  At that point,
what you're indexing into is a fixed-length array of floats or the
like, which quite the contrary - should be quite cache friendly, so
long as you're careful to access in order when you can (ie. component
instantiation and cases where you're operating on a component's entire
data set).

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?

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

-- 
Megan Fox
http://www.shalinor.com/
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.