Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Programming Collisions.

  1. #11

    Programming Collisions.

    I agree with records, I love them to do death .

    Really it matters not about structure because unless I take a big break I know the program inside and out with 100 lines of codes or 20 000 spread across multiple units.

    If I do take a big break, well I get confused with small things too anyway haha, but it does not take long to pick it up again, I use the same practices always which simplifies things.

    I just use bounding box collision, for my purposes it will generally be no problem at all, even with a lot of objects. I just do not bother checking un-used items in an array and if a collision is found I exit the loop, I generally do not need to test more than 1 object at a time, even if 2 collision occur (a wall and floor) it seems to work great.

    I am just stuck with an Asphyre specific issue at the moment lol.

  2. #12

  3. #13

    Programming Collisions.

    Well I'm certainly in favor of classes as I consider them to make larger projects much more readable and maintainable. But that's just my opinion. Each to his own.

    About Memphis example, I think that the main difference here is that memory is cleared when a class is created. This should be the only "delphi" stuff going on and you also often want to do that with records too.

    So for a fair test it should be something like:

    Code:
      for i := 1 to 100000 do begin
        New(ss);
        FillChar(ss^,SizeOf(TSomeStruct),0);
      end;
    ZGameEditor - Develop 64kb games for Windows.
    Thrust for Vectrex - ROM-file and 6809 source code.

  4. #14

    Programming Collisions.

    i disagree, altho it is easier in some cases, but created objects create a large overhead which you will not have from a block of memory (a record) if you want a really fast optimised game or engine, avoid using OOP at all costs.
    I'm sure this overhead is nothing to worry about. You should worry about optimizing the actual algorithm's for e.g Collision detection and efficient rendering. They will definitely give you a way larger performance boost than using records over classes.

    Like JDarling said, "under the hood" objects are actually records. There is no significant difference in speed, but there is a significant difference in structure and organization. At some point, only using records will prevent you from making more complex programs. Moreover you can more easily seperate different pieces of functionality, which results in more "modulair" code (you can replace pieces of code with other pieces easily).

    If you really want to use records for your projects, i'm not going to stop you. Some years ago i thought exactly the same, and i was sceptical about OOP. But once i got used to it, i never regretted learning it.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  5. #15

    Programming Collisions.

    well actually you are wrong.

    lets say, you create a game with many enemies, when an enemy dies, you delete the object, and when one spawns you create an object, reusing could be done, but if you use a record it would be quicker to delete and create a new (and it also depends on the sitation), with an object you will use twice as much time creating that object, then if you created just in a block of memory, ie a simple struct/record.

    anyone that has 'real' experience writing large simulations or games will tell you the same. classes do make things more readable, but they do have larger overheads, and when it comes to creating and destroying, a class is much slower, because they are managing things that most of the time do not need to be managed, they should be dealt with by the programmer.

    also when writing a game, why would you want to clear memory? infact writing any program, 9 times out of 10, you do not need to clear memory unless writing a specificed size of data to a file. a string you will end with a nullchar, sizes should be params to external procs so they can copy the correct amount of data.

    lets just say

    [pascal]
    v := GetTickCount;
    for i := 1 to 1000000 do begin
    sc := TSomeClass.Create;
    sc.Free;
    end;
    WriteLn(GetTickCount - v);

    v := GetTickCount;
    for i := 1 to 1000000 do begin
    GetMem(ss, SizeOf(TSomeStruct));
    FillChar(ss^, SizeOf(TSomeStruct), 0);
    FreeMem(ss, SizeOf(TSomeStruct));
    end;
    WriteLn(GetTickCount - v);
    [/pascal]

    now you will find

    objects = 203ms
    records = 110ms


    anyways i think this thread needs to get back on topic.

    ;MM;

  6. #16

    Programming Collisions.

    I ran your code and if you look at the times to allocate/deallocate classes and records, you are right.

    My results are:

    Classes: 156
    Records: 78

    Nevertheless, you normally don't create/destroy alot of classes per second. If you look at Meshes, Textures, Shaders, Fonts, GUI-Elements, etc... You'll see that you don't need to rapidly create and destroy them. Moreover most of the creation/destruction happens when a game starts and exits. So the actual gameplay will not be significantly slower, unless you decide to created/destroy hundreds of objects a second.

    However, In some cases it can be wise to use records e.g for particles in a particle system. I agree with you on that point.

    anyways i think this thread needs to get back on topic.
    I agree with you on that too.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  7. #17

    Programming Collisions.

    Quote Originally Posted by chronozphere
    My results are:

    Classes: 156
    Records: 78

    sorry offtopic again, but im interested as to knowing why your sample is faster than mine with same code, maybe compiler or something. what version of delphi/fpc did you compile with? i compiled using delphi 7.

    what is your processer speed? im running a 2.4 core 2 quad, also what speed is your memory etc? im running 800mhz ddr2 geil (with a very low latency)

    thanks in advance.

    ;MM;

  8. #18

    Programming Collisions.

    That's ok, the off topic discussion is very interesting, I am always interested in discussing performance .

    The Asphyre specific issue I have is with Render Targets of Asphyre 5. I used most of the basic render target example (but I have only 2 instead of 4) and want to use them in my editor.

    My first 1024x1024 target is perfect, the second however 320xINFINITE (depending on size of the tile graphic loaded) draws all imagery at a lower scale, and nothing I do seems to correct it.

    The developer of Asphyre said textures or something should be power of 2, I don't see why as the identical image draws fine on the first render target lol.

  9. #19

    Programming Collisions.

    Hmmm... That's odd. :shock: Your system seems somewhat faster than mine.

    I have an AMD 64X2 5400+ with 2gb of DDR2 RAM (I believe it was 667Mhz or something...). I compiled my code using Delphi 7 and i run Vista ultimate.

    I ran your code a few times and these are my average results:

    Classes: 200ms
    Records: 78ms

    The first time I run the code, the classes seem te be significantly faster (150ms)

    And you are forgetting something. You might run more applications in the background than me. I believe this will affect the performance too.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  10. #20

    Programming Collisions.

    offtopic:

    Why i favor records usually is because of Socket based games or saved data files.

    When with records you can simply send/save/read the entire record in 1 go with classes you have to individually process every single variable. However i know classes are packed in memory and you can point them from their first variable and find out size by pointer from last. But that is so nasty way that its not even considerable. Then again, if you put data records in a class, you might have used records to begin with

    But i do use classes whenever i can on bigger concepts, as controlling mechanism.

Page 2 of 3 FirstFirst 123 LastLast

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
  •