Best thing to do with dead entities during game?

Performance Tuning
#1

This is how I currently clean up dead objects.
It’s not a good way of doing so and must change.

During the game objects die, their hit points are at or below 0.

I’ve read many ways of achieving this goal but my current situation would mean I have to implement “isDead()” checks throughout my scripts and collision code.

Any alternative fast way of removing dead entities?

`
private transient Player pc;
private ArrayList characters;
private ArrayList scripts;

/*Clean up the dead/
public void cleanUpDeadObjects()
{
for(Iterator i = characters.iterator(); i.hasNext():wink:
{
GameCharacter character = (GameCharacter)i.next();

              if(character.isDead())
              {
                    J2DRenderQ.getInstance().remove(character);
                    i.remove();
              }
        }
  }

`

#2

That’s pretty much what I do, except I do it right after tick()ing the entity.

Cas :slight_smile:

#3

I edited my code to not render or do any collision detection.
So I can permamently erase entities or temporarily erase them.

During the game I’m worried that I will invoke the GC.

#4

You could maintain 2 lists of characters, alive and dead ones. Your render and logic code only really proccess characters that are alive. When a character dies you move it to the dead list.

If you need to spawn a new character ‘reset’ a dead one and move it back onto the alive list. This way you never have the GC kick in and remove objects since they’re always being referenced.

Andy.

#5

This is what I do in Cosmic Trip:


      public void update(float deltaTime) {
            // Update all actors
            for (int i = 0; i < maxActors; i++) {
                  if (actor[i] != null) {
                        if (actor[i].isAlive()) {
                              actor[i].update(deltaTime);
                        } else if (!actor[i].isLockedInUniverse()) {
                              actor[i] = null;
                              actors--;
                        }
                  }
            }
            sortActors();
            checkCollisions();
      }

As you can see, I just ‘null’ the reference of most Actors when they die and let the GC do it’s job, except the Actors with isLockedInUniverse() = true (things like bullets, things that get respawned very often) although I probably didn’t need to worry about them either.
You’ll also see that I use a raw array for keeping track of the Actors. I once moved to ArrayList, but it was a lot slower (it spent ages in ArrayList.RangeCheck() ), so I changed it back.
I should still implement my own List without range checking everywhere, but didn’t get around to it yet.

#6

Would that be better than just sticking to using arrays?

#7

Interesting.
I never thought a standard array would be faster than an ArrayList.

Sun has always touted the performance of their collections being superior to arrays.

[quote]This is what I do in Cosmic Trip:


      public void update(float deltaTime) {
            // Update all actors
            for (int i = 0; i < maxActors; i++) {
                  if (actor[i] != null) {
                        if (actor[i].isAlive()) {
                              actor[i].update(deltaTime);
                        } else if (!actor[i].isLockedInUniverse()) {
                              actor[i] = null;
                              actors--;
                        }
                  }
            }
            sortActors();
            checkCollisions();
      }

As you can see, I just ‘null’ the reference of most Actors when they die and let the GC do it’s job, except the Actors with isLockedInUniverse() = true (things like bullets, things that get respawned very often) although I probably didn’t need to worry about them either.
You’ll also see that I use a raw array for keeping track of the Actors. I once moved to ArrayList, but it was a lot slower (it spent ages in ArrayList.RangeCheck() ), so I changed it back.
I should still implement my own List without range checking everywhere, but didn’t get around to it yet.
[/quote]

#8

[quote]Sun has always touted the performance of their collections being superior to arrays.
[/quote]
ArrayList internally uses an array anyway, so ArrayList can never be faster than an array I would say…
It’s just more convenient than using an array because all things that need to be done to grow/shrink/remove elements is already done for you. But it’s doing RangeCheck() everywhere which takes lots of time if you’re doing lots of access to the ArrayList.

[quote]Would that be better than just sticking to using arrays?
[/quote]
Only for the convenience of being able to re-use it. There’s no need to change Cosmic Trip, the good-ole array works perfectly well but I can’t simply go and reuse the same code again (some things are specific to CT).

#9

I guess you could implement a faster ArrayList, there is an AbstractList class to do so.

The speed of the array vs ArrayList is really about the algorithms behind it. Sun have stated that ArrayList is faster than casual use of an array is because most people couldn’t implement custom algorithms that are better than Sun’s.

When you mentioned an array being faster than an ArrayList I immediately thought there was something wrong with the ArrayList.

It would be simple enough to implement a custom collection class and use generics on it and override the appropriate method where the range check is occuring.

#10

Why bother. I can’t believe ArrayList is causing any performance problems. You seem very keen to improve performance where there are no performance problems. Profile first, then optimize.

#11

The thing is, ArrayList has caused me some performance problems more than once because of the mentioned RangeCheck(). I agree for most things ArrayList is perfectly fine, but I could do with one without RangeCheck() to avoid loss of performance. And it’s easy enough to implement, so why not?

#12

I just checked out the ArrayList class. None of its code is anything smarter than I would write myself to handle array size changing or anything.

#13

so, you could do better? :stuck_out_tongue:

#14

Well, it’s all very trivial and there’s so little you can screw up in implementing a resizable array yourself…

#15

Exactly. Resize, fill. The getters are just linear time for loop searches. Everything’s just a no-brainer I think.