Results 1 to 10 of 25

Thread: CLASS vs. OBJECT and memory management

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Quote Originally Posted by Ñuño Martínez View Post
    I think I don't understand your code. Extending TSprites will duplicate the sprite list, and I don't get benefits.
    Not necessarily. It depends on how you are extending the TSprites class. If you are extending it by just adding additional methods to descendant class like in TMovableSprite it won't duplicate list since you are still accessing it through inherited methods or properties from parent class.

    Quote Originally Posted by Ñuño Martínez View Post
    And it's worst with the TPlayer class. I mean, create a "TPlayer" object will create a new list of sprites, doesn't it?
    Yes in case of TPlayer I do create a new array to store additional information that is not being stored in ASprites array.

    What is advantage of this?

    For instance during rendering phase you only need information about sprites positions, size and orientation. You don't need additional information that you might be storing in your objects like in-game unit health.
    Now if you are storing all that information in one array when the data from that array is put on stack the stack would contain the data that you need during the rendering phase and also the data that you don't need during rendering phase. So you will be able to fill the stack with information for limited number of units at once.
    But if you have one array which basically contains only data that that is needed during rendering phase you would be able to store relevant data for greater number of in-game units at once.

    On the other hand in a different part of your code you might only need data related to in-game units health (checking which units are dead, regenerating their health). Here it would also be beneficial if you only put relevant data about units health on the stack without other unneeded data like unit positions etc.

    Perhaps it would be more understandable if I create a mind graph representation of the concept

  2. #2
    Quote Originally Posted by Super Vegeta View Post
    IMO, with what you're trying to achieve, it would actually be simpler to just use records and have a "spriteType" field there. You can use the Case() statement to test for the type and call the appropriate procedure when needed. It may not look the prettiest, but it's the simplest way and there's no risk that compiler optimisations mess something up.
    Also, you can have a SPRITETYPE_NONE value for your spriteType, which gives you a way to have "NULL" array members for free.
    This is much like how Build works, and I think I'll go this way.

    Quote Originally Posted by Super Vegeta View Post
    Also, have you tried using a profiler? It may turn out that the memory accesses aren't really that much of a problem and you're trying to optimize the wrong thing.
    No, I didn't. I tried to use GNU's profiler a long time ago (+5 years) and it didn't work too much as it couldn't identify several Object Pascal stuff. It was useless. I should try again, may be FPC 3.0 works. [edit] I've just read at the Lazarus wiki that "Support for using gprof under Linux is broken in FPC 2.2.0-2.4.0; it is fixed in FPC 2.6+", which explains why it didn't work.

    Quote Originally Posted by SilverWarior View Post
    Perhaps it would be more understandable if I create a mind graph representation of the concept
    That would be great because I'm a bit lost.
    Last edited by Ñuño Martínez; 16-06-2016 at 04:39 PM.
    No signature provided yet.

  3. #3
    Can I read this thread as allegory to Object vs Record (with methods)

  4. #4
    Of course you can.

    By the way, I've discovered "records with methods" recently. May be they are a better approach for what I want/need as they don't need initialization/constructor and no inheritance is involved (AFAIK FPC OBJECT inherits from an internal TObject the same way CLASS does, doesn't it?).
    Last edited by Ñuño Martínez; 19-06-2017 at 12:03 PM. Reason: typo
    No signature provided yet.

  5. #5
    You definitely should use records, with the {$modeswitch AdvancedRecords} define set. The classic Turbo Pascal style "objects" are well known to be buggy (memory leaks, e.t.c.) and as far as I know they aren't being actively maintained or developled in either Delphi or FPC, and I see no reason why they ever would be again in the future.

  6. #6
    Yep.

    Actually I think I'll use what SilverWarior suggested: a CLASS containing all sprite information as an ARRAY of RECORDs.
    No signature provided yet.

  7. #7
    Yep! What about TObjectList and TDictionary ?

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •