Re: Existence Based Polymorphism

On 2 June 2010 13:31, <[email protected]> wrote:

>
> ----- "Richard Fabian" <[email protected]> a écrit :
> > On 28 May 2010 17:01, JS Zirani < [email protected] > wrote:
> >
> >> It is a bit out of topic, but I think you should say "OOP has
> >> pitfalls" instead of "OOP is bad". "OOP is bad" is really the wrong
> >> message.
> >
> > I've been thinking about this a lot over the last few months, and come
> > to think that if OOP was not "bad", then there wouldn't be so many
> > "effective C++" or "C++ gotchas" like books out there. How many
> > "pitfalls of procedural development" books have you seen?
>
> Not to derail your argument, but this is more a problem of "C++ is bad"
> than "OOP is bad". Although I love C++, I have to admit that the 1998 and
> 2003 versions of the language have just too many quirks to consider when you
> want to write serious code. The direct consequence is that the resulting
> code is often quite hard to read. The 2011 version is supposed to be simpler
> and to be defined in a better way in order to avoid many of the problems
> that required the publication of these books.
>
> And of course, procedural development typically don't have such books,
> because procedural languages are often far simpler than C++. In procedural
> languages, a symbol refers to a unique entity. In C++ this is no more the
> case (due to polymorphism and to other features such as namespace support (a
> symbol can have different definition depending on the namespace in whitch it
> is declared)). The same is true for assembly programming : I've never saw a
> book about assembly programming traps and pitfalls, but on the other hand I
> do think that requiring a whole project to be done using assembly
> programming is a bad idea :)
>

In games, we're still stuck trying to eek out the last droplets of
performance, so languages that get it right (do OO properly) aren't on the
radar for tripleA titles... I haven't chosen to discount other langauges,
the industry has. Also, there are other benefits to be had by not doing it
"properly".

My reality is one where I try to write games that are fast to develop, are
easy to debug and are simple to optimise when they are not fast enough. In
that world there are no languages that support all three out of the box.

Assembly falls short on the "fast to develop and easy to debug", and C#/Mono
fals short on the "simple to optimise" bit. Trying to get an in-order
processor to run fast with the common runtime is a trial of patience.


> > On the polymorphism side, I stumbled across a slight issue in C++ that
> > goes away completely if you use sparse components to provide existence
> > based processing to provide state information.
>
> This sentence is a bit unclear to me (but I'm French ; so my English is not
> as good as I would like it to be). If you could explain it, that would
> probably help me to see the interest of the technique.
>
> A component's existence implies state. "AmDamaged" table only contains
entities that are damaged. "GoingToTarget" table only contains entities that
are currently going to a target, and any entity in that table can transition
to "AtTarget" table once they get to their goal. the transition will not be
an object copy or move it would be a create and delete pair and can be
pushed back to end frame housekeeping. These are existence (in the table)
based processing versions of a state variables. Also they provide the basic
blocks for building decision table arguments (build a list of arguments for
table "GoingToTarget", and see if any fulfil the requirement to destroy
themselves and create a new "AtTarget" entry. If so, output the decision to
the two decision output tables that correlate with these two different
tasks.

>
> > I've already touched on this with replacing bools and enums with table
> > entries, but the lovely thing about this is that you get stronger
> > polymorphism than C++ virtuals, without the virtual call cost.
>
> The virtual call cost is highly overrated. Sure, it shall not be used in a
> high performance loop - but with recent compilers, it often translates to a
> memory lookup (get address of a function depending on the value of this) + a
> jump + the regular function call. I would be surprised if your code is as
> efficient as this in release mode. As always, code, measure, decide :)
>

The cost of the virtual call is hidden in the fact that it calls "whatever
code is appropriate".
Now, think about how the decision table solution fits: It processes all the
elements in the table that would have this virtual call. At once. That's all
the same code. The overhead of virtuals is not the double de-reference, it's
the code cache being missed as you switch and change what code is doing the
processing on a per entity basis. Clumping all your different reactions to
state into groups removes that I cache miss almost completely.

Also, thinking about concurrency, virtuals don't let you set affinity by the
code being used. By definition, you do not know what will be run, so
grouping and batching off processing onto hardware processors is impossible
to do simply. Batch processing directly will always return better than
setting off functions without due care and attention.

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