goldsam / artemis-framework Goto Github PK

What steps will reproduce the problem?
1. Create an Aspect like this

Aspect.getAspectForAll(LayerComponent.class).one(PhysicsComponent.class, 
PositionComponent.class)

What is the expected output? What do you see instead?

You expect that all Entities must possess LayerComponent and one of 
PhysicsComponent/PositionComponent.

What version of the product are you using? On what operating system?

a609b2076aacc0ef5ecf0b390205d01bb88ceae2

Please provide any additional information below.

I think the issue is due to the missing check for the "interested" variable in 
check(Entity e).

// Check if the entity possesses ANY of the components in the oneSet. If so, 
the system is interested.
        if(!oneSet.isEmpty()) {
            interested = oneSet.intersects(componentBits);
        }

The provided patch scans any super class of the provided entity system for 
fields with the @Mapper annotation. This allows the super class to declare 
component mappers and have them instanced by reflection.

I've also added a check to see if the field has already been instantiated 
(field.get (target) == null). This could be useful if a super class declares a 
static component mapper.
Declaring a static component mapper is not recommended, I suppose, but I figure 
its best to cover all bases in this case.

TL;DR: I want an OrderedBag implementation so that I only have to call 
glUseProgram once per OpenGL ES 2.0 shader.

Hi Artemis devs. I really like the library and it seems very nice so far. I was 
just integrating it with a libgdx game I am making and I was trying to make a 
RenderSystem for objects that use OpenGL ES 2.0. As you may know, it is more 
efficient if you do not repetitively use the glUseProgram method. It is much 
nicer to call glUseProgram once per shader and render everything that uses that 
shader in one hit. Therefore I was wondering if we could possibly add in an 
OrderedBag implementation to Artemis. It may be a little bit slower but it 
would guarantee that I could get speed improvements while the program was 
actually running and when everything was finally in the bag. 

1. Fill a bag with 10 elements
2. Call bag.set(4, newitem);
3. Check bag.size();

bag.size() should still be 10, since there are 10 elements in it regardless of 
the fact that we just changed the 5th element using set.

bag.size() is instead 5, since the set call incorrectly changed it's size.

This bug has been fixed in a number of artemis ports from what I saw. The fix 
is to surround the size = index+1; statement with if (index >= size) {...}, to 
only change the bag's size if the new item being set is past the current size.

What steps will reproduce the problem?
1. Create multiple threads
2. in each thread create a World, add entities and systems
3. call world.process() a couple of times

What is the expected output? What do you see instead?
processEntities() in some EntitySystems is never called.

What version of the product are you using? On what operating system?
artemis-a609b2076aacc0ef5ecf0b390205d01bb88ceae2.jar, Windows 7 64bit

Here is the actual issue:

private static class SystemIndexManager {
    private static int INDEX = 0;
    private static final HashMap<Class<? extends EntitySystem>, Integer> indices = new HashMap<>();

    private static int getIndexFor(Class<? extends EntitySystem> es) {
        Integer index = indices.get(es);
        if (index == null) {
            index = INDEX++; // INDEX is static, accessed in ALL threads
            indices.put(es, index); // same issue here
        }
        return index;
    }
}



Solution:
Make one local SystemIndexManager object for each World instance, or simply 
something like this:

private static class SystemIndexManager {
    private static class Indices {
        public int INDEX = 0;
        public final HashMap<Class<? extends EntitySystem>, Integer> indices = new HashMap<>();
    }

    private static final ThreadLocal<Indices> threadLocalIndices = new ThreadLocal<Indices>() {
        @Override
        protected Indices initialValue() {
            return new Indices();
        }
    };

    private static int getIndexFor(Class<? extends EntitySystem> es) {
        Integer index = threadLocalIndices.get().indices.get(es);
        if (index == null) {
            index = threadLocalIndices.get().INDEX++;
            threadLocalIndices.get().indices.put(es, index);
        }
        return index;
    }
}

Using static methods is very convenient but the current naming convention could 
be simplified. I suggest following the Guava naming convention. For example

Aspect.getAspectForAll(Position.class)

would be no less clear than:

Aspects.all(Position.class)

Moving these static constructor methods to a separate file (Aspects.java) would 
remove some clutter from Aspect.java. This would also let us add some extra 
methods with varying numbers of component types to prevent the need for 
@SuppressWarnings("unchecked") annotation throughout the users code (again 
similar to Guava).

For reference, I've included the Aspects class I'm currently using.

The ImmutableBag class has scope to extend the Iterable interface. The concrete 
classes such as Bag can implement those iterators.

Then it would be possible to use java's built in enhanced for loop:-

ImmutableBag<Entity> monsters = 
world.getManager(GroupManager.class).getEntities("MONSTERS");

for (Entity monster : monsters)
   monsters.doStuff();

If gaps are left in a Bag when setting items, the size method stops being 
reliable. For example:

Bag b = new Bag();
b.set(5,new Object());
b.remove(5);
assert b.isEmpty();

will throw an AssersionException because the size of the bag is considered to 
be 6 after setting an item at index 5, and 5 after removing that item.

What steps will reproduce the problem?
1. Subclass and add an EntityProcessingSystem with a ComponentMapper field 
which has a generic type of a Component matched by the System's Aspect.
2. Add a Component of the mapped type to an Entity, inserted() is invoked and 
the component is present in the ComponentMapper.
3. When a Component of the mapped type is removed from an entity, removed() is 
invoked, but ComponentMapper<>#get(e) returns null.

What is the expected output? What do you see instead?
In removed(), ComponentMapper<>#get(e) should return the component that is 
being removed.


What version of the product are you using? On what operating system?
artemis-a609b2076aacc0ef5ecf0b390205d01bb88ceae2.jar
OS X 10.8.4
Please provide any additional information below.

What steps will reproduce the problem?
1. Create a World
2. Create a Entity and give it a 5 varying Component types
3. Call Entity refresh()
3. Call World loopStart() to refresh everything
3. Get the Entity components with getComponents() method or use a breakpoint to 
browse the contents of the EntityManager componentsByType list.

What is the expected output? What do you see instead?
I expect to see 5 components.  Instead depending on the ID of the Entity in my 
tests with only 1 entity in the World the getComponents() method returned 2 
components when it should've returned all 5.

What version of the product are you using? On what operating system?
Latest source from this.

Please provide any additional information below.
I found a work around is to create 50 or so Entities with all my components so 
that the componentsByType list has all the component bags initialized.

In GroupManager the following is used for String comparison:

                if(group == g || group.equals(g)) {
                    return true;
                }

This kind of micro-optimization isn't necessary, the jvm developers are 
perfectly aware of String interning and the implementation of String.equals 
includes:

        if (this == anObject) {
            return true;
        }