CLASS vs. OBJECT and memory management

[Ñuño Martínez]

(...)

I think I don't understand your code. Extending TSprites will duplicate the sprite list, and I don't get benefits. And it's worst with the TPlayer class. I mean, create a "TPlayer" object will create a new list of sprites, doesn't it?

Not really. When using virtual methods, each object must also contain a "secret" member that points to the VMT. Setting up this pointer is done by the constructor, so if you typecast some of the objects in the array and call the child constructor on them, the VMT will be properly initialized to that of the child class. One important thing to note here, though, is that the descendant classes cannot declare any new fields, since they would be located after the base class data, thus accessing them would go past the base class memory area and mess stuff up in the next array member.

You're right. If descendant classes use the same data than the parent ones then there's no problems. I see it. The problem is how to know which typecast to use. May be a "SpriteType" field will do the work but I find it quit ugly:

  FOR Ndx := LOW (SpriteList) TO HIGH (SpriteList) DO
    CASE SpriteList[Ndx].SprType OF
      stPlayer : TSprPlayer (SpriteList[Ndx]).Update;
      stBullet : TSprBullet (SpriteList[Ndx]).Update;
      stEnemy1 : TSprEnemy1 (SpriteList[Ndx]).Update;
      stEnemy2 : TSprEnemy2 (SpriteList[Ndx]).Update;
      ELSE SpriteList[Ndx].Update;
    END;

Using a "CLASS OF ..." field may fix the problem, but I think it's not possible...

  TYPE
    TSprite = CLASS; { Forward declaration. }

    TSpriteClass = CLASS OF TSprite;

    TSprite = CLASS (TObject)
    PRIVATE
    { ... }
      fSpriteClass: TSpriteClass;
    PUBLIC
    { ... } 

      PROPERTY SprClass: TSpriteClass READ fSpriteClass;
    END;

{ ... }
    FOR Ndx := LOW (SpriteList) TO HIGH (SpriteList) DO
    { This doesn't work. }
      SpriteList[Ndx].SprClass (SpriteList[Ndx]).Update;

Anyway, I'm reading Game Programming Patterns (you should read it even if you don't like patterns, actually I don't like them but the book gives a lot of good ideas) and I've found some information. What I'm asking for is an Object Pool, as you have all objects and reuses them when needed. This is the way Build works, for example.

Also I've found a problem about microprocessor caches: if using a scripting (bytecode ) to define the behavior of sprites (allowing a way to keep size of all TSprite while extending them), anytime a script is executed it may kill the cache.