chrismweb

I have been doing my animations using 800x480 graphics, and changing out the texture atlas for higher quality images for higher resolution screens (and smaller atlases for lower screens).

I use a scaling factor for scaling the images to the same size on runtime (so all end up being the same dimensions as the 800x480 images).

Can Spine handle different resolution textures with he same animation?

(An additional question: If you have a character with quite a bit of textures, and need to use multiple texture atlases, can it support that as well?)

[edited - thx Shiu :D]
Аватара пользователя
chrismweb
  • Сообщения: 135

chrismweb

Hey, got to the point that I was actually able to test it, and the answer is YES! can use other resolution atlases.


BUT - do you know if you can use multiple texture atlases? I have enough parts that they won't all fit on one texture atlas.

With my older game, I had to split it up on 4 different atlases- is it possible to do that? Or another solution?
Аватара пользователя
chrismweb
  • Сообщения: 135

Shiu

Hey christmweb, glad you got it working.

The short answer to your second question is. Yes you can use multiple texture atlases. Nate will give you a more detailed answer for it later.

Oh by the way, its Spine, not Spline ;)
Аватара пользователя
Shiu

Shiu
  • Сообщения: 2382

Nate

When you pack your images the packer should have a max texture size and be able to pack the images into multiple pages. So you have one atlas but it has any number of texture pages. If your packer can't do it, get a better packer: :)
http://code.google.com/p/libgdx/wiki/TexturePacker
Аватара пользователя
Nate

Nate
  • Сообщения: 9264

chrismweb

Thanks Nate!

I am using TexturePackerGUI by Andreas Loew / code-and-web.de, but I'll switch to that for the multiple pages :D

But - could there possibly be problems if say every other TextureRegion was on different textures? Since it would have to be swapping back and forth between each texture?
Аватара пользователя
chrismweb
  • Сообщения: 135

chrismweb

I guess you do have it so you can sort the order of drawing textures out in the spine interface, so that problem could be minimalized.

I was able to replace my animation system with yours in about a day luckily source for libGDX was available, so could slightly modify stuff)!
(off topic) How long did it take you to create both the spine program and the first run time? ( assumably libgdx)?

It took me between 1-2 months to get a similar "runtime", animating in flash, and converting the XML into a simplified format I could use in game. But your solution is much more elegant, and complete :D
Аватара пользователя
chrismweb
  • Сообщения: 135

Shiu

I don't know exactly how long the runtime took, but we have been working on Spine for about 7 months.

Nate has been traveling all day, which is why he hasn't been able to reply to your question. I'm sure he will take a look at it tomorrow if you still have questions about the texture packer :)
Аватара пользователя
Shiu

Shiu
  • Сообщения: 2382

Nate

I have a feeling Andreas' texture packer can output multiple pages for one set of images. Both tools are good, I just prefer how mine is configured (via directory structure and pack.json files), that mine is free, and of course that I wrote mine. ;)

Yes, if every other image was on a different texture you would have lots of texture binds. Ideally you use one texture per skeleton so this doesn't happen. Separating images into separate textures based on draw order could work.

If you have so many images that they can't fit on a single texture, then you could pack your images into a texture at runtime. Compute which images will actually be used on a skeleton, then use PixmapPacker to pack the images at runtime into a texture. This is less flexible because you'll need to know what images you might use beforehand, but can make it efficient to draw when you have hundreds or thousands of possible image attachments.

Spine took about 7 months to build, one artist and one coder both working full time (basically all the time!). It uses libgdx, which is an enormous amount of effort. scene2d in libgdx took many months and iterations to build. Spine isn't the first large scale scene2d based application, which meant a good deal of scene2d was already solid, but it is the first large scale desktop scene2d based application, so a little bit of time was spent improving it for the desktop.
Аватара пользователя
Nate

Nate
  • Сообщения: 9264

chrismweb

Awesome, thanks for the info!

Well, it's good to know that it's not 2 months of work on the program and run time- but even 7 months is pretty fast for coding all of that, with all the little features in there!

Did you use "swing", or other libraies at all for spine, or is it all just LibGDX and scene2d?
Аватара пользователя
chrismweb
  • Сообщения: 135

Nate

Yeah, a lot of time has gone into polish and tons of minor features, eg making the tools easy to use -- there is no selection tool! If we were using it only for ourselves we wouldn't need a slick and easy to use interface and could have been done a lot sooner. That would also mean we wouldn't need to build a bunch of runtimes, which brings oh so much pain. ;)

The only Swing used is to set up the window frame. All of the drawing and everything else is libgdx/scene2d/tablelayout.
Аватара пользователя
Nate

Nate
  • Сообщения: 9264


Вернуться в Editor