Slick Forums

Hey all,

I'm just starting to get into game development and have been playing around with Artemis to build an Android Tower Defense game (libgdx based). I really like the flexibility of an Enitity System and Artemis has a very clean intuitive implementation. However, there have been a few things that have really bugged me about it. First, the Bag implementation seems unnecessarily complex and buggy (from what I've seen on issue trackers of various forks). Second the memory management in Artemis is pretty atrocious.

Since the library doesn't seem to be actively maintained anymore, I took it upon myself to do some refactoring to make it a little more mobile dev friendly.

The result is here: https://github.com/apotapov/gdx-artemis

It's still very much a work in progress. I still need to do a bunch of cleanup. But for now the changes made seem to be pretty stable.

Any comments or suggestions are appreciated.

Thought about replacing Bag with Array - and pull in some other code from libgdx - too, but in the end decided to keep the old classes.

I would have preferred if the original package names were retained, would make adoption easier/less invasive.

Have you thought about removing the libgdx dependency? Or, more generally, does your fork exploit libgdx in some way?

_________________
agrotera: bytecode-weaving antiboilerplate lib for artemis. | artemis-odb: bugfixing and performance optimized fork.

Thanks for taking a look.

At first, I tried doing exactly that, just copying the libgdx Array, ObjectMap and Pool over. However, they had too many other dependencies in libgdx to do it cleanly, so I decided to bite the bullet and just make libgdx a dependency.

As for package structure, I agree that it would be better to keep the original one. However, I'm hoping to roll this into libgdx as an extension and figured that I might as well adjust the package structure to make it more suitable to do so.

To be honest I wasn't a huge fan of how things were organized in artemis. They were trying to be extra safe with encapsulation by relying heavily on private and package protected fields/methods. This made rolling a custom Enity and Component managers, for instance, a huge pain. (which what I tried to do first to implement pooling) I wanted to make Artemis more open for extension without having to jump too many hoops.

I submitted an issue to libgdx github wrt this project: https://github.com/libgdx/libgdx/issues/789

I wouldn't mind rolling the package structure back, but that depends on whether libgdx guys are willing to add this as an extension.

I thought I posted a reply to this, but I don't see it here.

After seeing that the libgdx team did not want to roll artemis in as an extension, i reverted the package structure.

As for the libgdx dependency, my first attempt was to just copy the relevant libgdx code to Artemis (Array, ObjectMap, Pool, etc) However, those classes had a ton of other dependencies in libgdx, so extracting everything seemed more trouble than it's worth. So I decided to bite the bullet and make libgdx a dependency.

I took a look at your project and seems like you guys added a few nice features. What are your thoughts on combining our efforts?

Update:

I've made quite a few improvements to gdx-artemis (https://github.com/apotapov/gdx-artemis) since I've last posted on here. The library is now at version 0.3.

Notable differences between the original Artemis implementation and gdx-artemis:

* Uses libgdx containers and pooling.
* Event (messaging) system was added (version 0.2)
* Better GWT and HTML 5 support. ComponentMappers need manual instantiation.

There is now a Wiki Page: https://github.com/apotapov/gdx-artemis/wiki. The manual section is still a work in progress.

There is also a runnable demo project https://github.com/apotapov/gdx-artemis-demo

Up next, I'm looking to add a demo for using the Event System. Going to continue working on documentation and adding unit test.

If you have any suggestions for improvements please file a ticket in Github, or submit a pull request. (I rarely check this forum)

Hello apotapov!

i've just read this topic searching info on artemis performances on Libgdx games.

can i ask you what are the problems you encountered using the original Artemis lib in libgdx games?

I've just started using the Artemis base build for my new game and before go over with it i would like to know if i'll have some kind of problem in performance or in some specific platform build etc...

feel free to add any suggestion about it.

Thanks.

Chiming in since I'm here now.

Generally speaking, artemis' overhead is very low. You get typical type of performance degradation over time as cache misses increase due to sprinkling objects (components) all over the heap - true for most things java as there's no language-level support for memory aligning objects.. For most games this isn't a problem however.

Vanilla artemis had some potential GC hickups on android, as 5 objects with a nested bag are spawned every tick. The JIT would take care of it on desktops though (haven't tested it myself, but sounds reasonable). There were also some for-each loops (spawning an Iterator).

_________________
agrotera: bytecode-weaving antiboilerplate lib for artemis. | artemis-odb: bugfixing and performance optimized fork.