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