True, though it depends on the game (eg, 4k games). An obfuscater can rip out all the stuff you don't use, which might be a decent chunk if only using small portions of relatively large libraries. FWIW, Spine is ~43k LOC on it's own, not including dependencies. The JAR including that and all the dependencies (libgdx, LWJGL) is 2.2MB, without natives. Kind of scary how much effort goes into something so small. Unobfuscated it's 3.9MB, so a 44% reduction. The JGLFW version of Spine is < 1.5MB obfuscated, which goes to show LWJGL could be a bit smaller.

It can make a big difference trying to decompile code obfuscated vs unobfuscated. It is still possible, just harder. It also makes the JARs smaller. There is nothing wrong with obfuscation.

The origin is a runtime specific thing. You can move the root bone so the top left is at the origin, then when you rotate whatever container is rendering the skeleton, it will rotate where you want.

I use it for Spine, a desktop animation tool. Building Spine caused scene2d to mature for building desktop apps.

Do some best guesses to get it somewhat close to how you want, then use a binary search to adjust anything you don't feel works well. Eg, if a gun feels too weak, don't mess around adding 10%, 15%, etc to it's power, just double it until it is too powerful, then weaken it by half the amount you last increased it, etc. This gives you a wider range of testing and you converge on a good value much more quickly than constantly fiddling with the numbers.

I tend to use the LUT in games and libgdx itself, but other libgdx contributors don't. In fact they seem to actively change libgdx to not use the LUT. Eg, scene2d no longer uses it. I haven't investigated their reasoning, but I assume they don't feel it is accurate enough. Maybe when compounded?

You could include the region in an atlas if you only need to repeat in one direction, you just need to set the max size of the atlas page the region is on to your POT image size.

To render a region repeatedly without using the repeat wrap mode, see TiledDrawable.

NONSENSE! 

Cool. Where do you keep your latest version?

I use + half PI for cosine to double the accuracy with the same memory at the cost of + half PI. Since everything is jammed inside the MathUtils class, I used static classes so the tables aren't initialized unless actually used.

You need to give SpriteBatch UVs using:
draw(Texture texture, float x, float y, float width, float height, float u, float v, float u2, float v2)
The UVs are from 0 to 1, where 0 is the top (v) / left (u) and 1 is the bottom (v) / right (u). You can use values outside this range and it will repeat. Eg, use 0,0,2,1 and it will repeat twice horizontally and once vertically.

You can also use a TextureRegion to specify the UVs. Also see the TextureRegion scroll method.

FWIW, libgdx has sin/cos LUTs based originally based on Riven's:
https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/math/MathUtils.java

setTextureWrap(TextureWrap.GL_REPEAT) on the texture. Or specify the wrap when using TexturePacker2. Or use TiledDrawable.

Cool! You can also attach an image in Spine that you avoid drawing at runtime. You can then get the vertices of this image at runtime. Note it can be a quadrilateral (rhomboid), so you can use polygon intersection testing. This is better than just a bounding box, as it will move, rotate, and scale with the bone it is attached to. This is essentially what the bounding box feature will do.

Here's Java code to do it:
http://www.esotericsoftware.com/forum/viewtopic.php?f=3&t=34&p=147#p147
It's slightly outdated, but that is how it can be done. Note with an animated skeleton you might want to compute this every frame.

TableLayout supports Swing.
http://code.google.com/p/table-layout/

Dead.

Maybe could use more description about what it is?

Needs some swimsuit girls.

Now with onion skinning!

Check the KryoNet JAR on the Android project export settings.

I enjoyed reading it, good food for thought!

I added a section on running it from the nightlies a week or so ago:
https://code.google.com/p/libgdx/wiki/ParticleEditor#Running_the_Particle_Editor

There should be no problem "type" or any other field name. o.O Probably you classes were out of date, as I said.

Not sure then, you'll have to debug it, debug/trace logging, simpler testcase using only Kryo, etc.

Probably you have mismatched classes on either end of the network.

I bundle an OpenJDK JRE with Spine. Weighs ~13MB.
https://code.google.com/p/libgdx/wiki/BundlingJRE

Refactoring is an important part of being a developer. I'd even say if you aren't good at it or you don't like it that you are limiting yourself. I write code relatively loosely so I don't waste time perfecting code that might not be used. As I progress I go back and improve the code I'll actually be using. A developer that skips this step generates relatively low quality code. You need to hold the entire part of the code you are working with in your head and thoroughly understand it, have a plan for rewriting or restructuring it, and then implement that plan.

Refactoring is generally to improve the design of your code. It is easier to see what is needed so everything fits together nicely after you have something working, and you can still do so with an eye toward the future of the program. Optimization is different. First, it shouldn't be done at all unless there is a problem. That is a hard and fast rule. It is hard to follow, but it exists to keep you from wasting your time and making your code unreadable. Second, see the first.

@heisenbergman, yes.

Yep.