Allow to resort entities

[Stef569]

Allow to resort the entities in the world if you change the depth of an entity after it's creation.

see http://slick.javaunlimited.net/viewtopic.php?f=10&t=2702&p=26026&hilit=marte+engine#p26024

[Gornova]

we need a method to change depth, and update entity orders using sort

[Stef569]

well :P let's do this in entity, making depth private.

then entity.setDepth(int newDepth) will set the depth and resort all the entities in the world.

I wonder what will happen if you set the depth while the entities are updating, changing a collection while iterating, not good.

The entity could tell the world that a depth has been changed and when all entities have been updated then resort the entities.

[Regiden]

iterating over enties while they could change is easy:

for (int i = 0; i < entities.size(); i++) {
    Entity e = entities.get(i);
    if (e.isAlive()) {
        e.update();
        if (e.isAlive()) {
            checkList.add(e);
        }
    }
}
ArrayList<Entity> temp = entities;
entities = checkList;
checkList = temp;
checkList.clear();

entites and checkList are global lists. The thing is the for loop should not be a foreach. With this code you can dynamically update the entites while adding some or deleting them.

This is a 2D engine right? So depth should be sorted by y + depth. where depth adds or subtracts a bit so an entity will be overlapped in the center of it'S image or something :)

[Stef569]

The entities overlap based on their position in the entities list. A new depth == resort the collection. see https://github.com/Gornova/MarteEngine/blob/master/src/it/marteEngine/World.java#L157 What happens if you do Collections.sort while in your for loop?

Not sure about y + depth, if entities will overlap then the user should define his own depths, why the y?

You are right about adding/removing entities while iterating. Your way is better =)

[Regiden]

Oh this is not my way^^° It's from Cas from Puppygames. He somewhere posted this awesome way of updating entities :) So all credits goes to him!

That should not be a problem if you separate update and render. in update you just update all entites. The order is normally meaningless. but before rendering you sort them along the depth values. And rendering should not change the depth right?

About Y. Consider this: We Have Entity A And Entity B. Both are 16x32. Now A is behind B like this:

A
B

Since B has a height of 32 pixel you will not see A (or maybe just a bit). Now as A moves down along the Y axis it will then be before B.

B
A

No A overlaps B, because we sorted with the Y Axis :) And the offset tells you at which point this should happen. This example would overlap B as soon as the top left corner of A has a higher Y-Value as B. with the offset of -16. It would already overlapt B if it's half way through.

Of course the developer can set the depth value to Y. So you can use a depth values easily.