I’d like to use Gemserk’s commons-gdx library in my libGDX project but failed so far. I cloned the github repository and tried to build a jar, with mvn package, but it failed because it could not resolve the following artifacts: com.badlogic.gdx:gdx:jar:0.9.8-SNAPSHOT, com.gemserk.animation4j:animation4j-core:jar:0.2.2-SNAPSHOT, com.gemserk.vecmath:vecmath:jar:1.5.3-GEMSERK
What should I do to get a commons-gdx.jar? 
I downloaded the jars and installed them with maven, but still no luck:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project commons-gdx-core: Compilation failure [ERROR] error: error reading C:\Users\me\.m2\repository\com\gemserk\vecmath\vecmath\1.5.3-GEMSERK\vecmath-1.5.3-GEMSERK.jar; error in opening zip file [ERROR] -> [Help 1]
Installed the vecmath-1.5.3.jar from here: https://code.google.com/p/gemserk-maven-repo/source/browse/maven/thirdparty/java3d/vecmath#vecmath%2F1.5.3 Or should I use jar with sources?
The vecmath jar was actually corrupted, but managed to find a good one, now it starts to compile, but runs into a compilation error:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project commons-gdx-core: Compilation failure: Compilation failure: [ERROR] C:\..\..\..\Workspace\commons-gdx\commons-gdx-core\src\main\java\com\gemserk\commons\gdx\games\SpatialPhysicsImpl.java:[32,6] cannot find symbol [ERROR] symbol : method setTransform(float,float,float,boolean) [ERROR] location: class com.badlogic.gdx.physics.box2d.Body [ERROR] C:\..\..\..\Workspace\commons-gdx\commons-gdx-core\src\main\java\com\gemserk\commons\gdx\games\SpatialPhysicsImpl.java:[45,6] cannot find symbol [ERROR] symbol : method setTransform(float,float,float,boolean) [ERROR] location: class com.badlogic.gdx.physics.box2d.Body [ERROR] -> [Help 1]
I shouldn’t have used the nightly libGDX build, with the 0.9.8 jar it starts the test…which are failing…
Tests in error: testConvertFromHexString2(com.gemserk.commons.gdx.graphics.ColorUtilsTest): com.badlogic.gdx.graphics.Color.set(FFFF)Lcom/badlogic/gdx/graphics/Color;
Ok I think I give up. Skipping a test (which I know was not a good idea) reveals that there are further missing artifacts:
[ERROR] Failed to execute goal on project commons-gdx-android: Could not resolve dependencies for project com.gemserk.commons.gdx:commons-gdx-android:jar:0.0.11-SNAPSHOT: The following artifacts could not be resolved: com.adwhirl.adwhirl:adwhirl:jar:3.0.0, com.google.ads.admob:admob:jar:6.0.1: Failure to find com.adwhirl.adwhirl:adwhirl:jar:3.0.0 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
The things I was interested about in the library were the svg parser and the screen and stage system. Guess I have to create my own or look for other libraries.
Yay for Maven! 
Screen and Stage are easy to create. Since it is open-source just read on their svg parser and make your own.
Indeed. Guess its not a bad tool if you work on common business stuff where most libs are in a public repository.
Gemserk’s solution looked really polished and didn’t want to waste time rewriting my code because I’m not happy with it. But I think should just think of it as a part of my learning process becoming a good game dev.
Hi @nosferat, glad you tried to use our solution, however I have to clarify some stuff. Our code is open source just for the purpose of share the things we do, not as a library but as reference for other people to look for. Why not as a library? because we use a lot of stuff that are not on maven central and that sucks when trying to share your library, for example, libgdx is not on maven central and even though we created a mavenizer for it, we still need to upload it to sonatype and upload other libraries we use also. So, that is one of the reasons we don’t share it as a “use this library” because it is not going to be easy to make it work. Another reason we typically say to people who want to use our library is/was that we are/were making changes all the time and it could not be stable, and we like it that way since it is a library mainly for our games, so it needs to change to adapt to us.
TLDR use it mainly as reference, it was not made to be easily usable as a library, but was a decision, it is not because maven sucks (yeah, I am looking at you @nate).
My recommendation is, just copy paste the packages you need whenever you can
Good luck.
Yeah they are polished, but what is more important to have base code that suits your need. I am building a repo (not lib) of what classes I commonly use on every project, like button that has press effect, Animation class that takes Drawable rather TextureRegion, etc. I feel more comfortable this way https://github.com/drabiter/gdx-plate/
Not sure if arielsan will read this topic again, but might aswell try:
If copied the GpuMemUtils class, tried it and have an elemental problem with it:
I poll a new update per key whenever I change map and stuff, to look at the gpu ram usage. But it always gets up, it never ever goes down.
After many map changes I have like 3000MB, which is of course impossible and after even more mapchanges it changes to a negative value, like -1180 MB
I should mention that we had a similar kind of behavior using tools like GPU Z and stuff, which are made specifically for this analyses…
But it seems that ram on the gpu just behaves strange and you can’t really GET the current value - at least thats my conclusion trying this type of thing across various machines with various tools
The strange part is we are not accessing the GPU at all when calculating the GPU usage but LibGDX managed textures map, so it should be pretty direct but at the same time it could not reflect the real GPU usage.
yeah I know actually, looking at the code and knowing that its not possible with java…
but yeah its very strange, seems like you can just never measure the gpu
basically what we do is just calculate it on paper and guess “its about this much and it should be ok…” there has to be a better way =D
maybe Nate or Mario know something
We had a bash script to calculate the total size given the images packs but the idea of calculating the GPU texture size in runtime is to know how much we are consuming on each game screen so we could try to optimize the related textures. Also, calculating that in runtime gave us some idea if something was wrong, for example, if we weren’t releasing some textures the GPU memsize would increase when moving from one screen to another and then returning.
well I always saw this trend of increasing gpu mem usage but I never got a gpu out of memory error or something
I also THINK we release whatever makes sense, gotta check with my opengl programmer again
but yeah I ran the game on quite weak machine and laptops with shared memory and whatnot and never got something like a gpu out of memory error or whatever, but the tools IMPLY we have a gpu memory leak
but I remember leaving “gpu z” on with commercial games and the stats were also all over the place, not making much sense