Re: sparse components

Richard Fabian wrote:

> Tom Plunket wrote:
>> The performance requirements for something that you're doing once a
>> frame is a lot looser than the requirements for something you need to
>> do a million times a frame.  Folks who say "OOP is bad" miss the point
>> (as has previously been pointed out).
>
> Yes, but if the number of different things you do once a frame outnumber the
> things you do 10+ times a frame, you're probably affecting the frame rate
> anyway. Death by a thousand paper cuts style.

Perhaps.  The thing is, this whole discussion seems oriented on
formatting your data for "stream processing," e.g. the process starts
at the beginning of the input stream and works its way to the end,
while writing an output stream.

I don't know anything about database development beyond the most
simple select queries, but to me the similarities just aren't there
with what I see.  The database is ostensibly a homogenous "data
structure" in that the schema defines the row format and we can select
matching rows so we can do processing on those rows.  To me, the whole
"homogenous array of components" discussion looks more like a table
that can be presented as a stream and there are no decisions about
what elements require processing because they're all processed.

I'm not trying to say that the SQL-like approach has no merit, more
that I can't judge it.  What I am saying is that you want to have as
little logic as possible between the in-memory format of your data and
the processing of that data.

To me, the valuable change of this approach was not for the
queryability of the data, indeed it was just the opposite.  As I've
developed my own coding styles I've adopted a "tell, don't ask"
methodology almost completely devoid of queries of state.  For any
processing that needs to get done, the required state is /explicitly/
handed to it.  This (perhaps obviously) maps very well to "stream
processing" since it's a move from "work on one thing then work on
another thing" to "work on all of these things that are the same".

To come back to my earlier point- the problem isn't OO vs. procedural
or functional.  Any of these methods can operate as horribly as any
other.  Functional is no more of a magical bullet than OO was; the
people who are using it now are the ones who understand it and are
working to its strengths.  As Mat N. says, OO or not is an orthongonal
consideration to data layout; there's no reason why homogenous arrays
of data can't individually be treated as "objects," and in some
programming contexts it may even be appropriate.  Arguing that OO
cannot be used on a given data set is no different than arguing that
it must be used.  The key question is one of the costs of your present
abstraction?

Death by a thousand cuts it may be to have "gameplay" use heavily OO
code, but if so it's not the OO part that's causing the issue.  It's
the programmers not understanding the costs of their decisions.  It
may be perfectly reasonable and not appreciably more costly to move
the camera through the world or read the controller input in an "OO"
way.  It may add a small amount of time to that operation, but it also
may save development time and may clarify intent so that a robust
solution is more easily maintained.  It's hard to say for sure without
seeing the specifics.

That is why I say that the blanket black and white statements are
always wrong; one cannot make the statement "X is bad" without
understanding the context within which it is used.  Well, unless X is
"globally accessible mutable state" aka "globals and singletons".  ;)

-tom!

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