Hello alcyongames, sure, of course you can export various sizes (even all in one single export) using Spine.
you just need to write a number where 1 equals 100% export size, and for example, 0.5 equals 50% export size:

In this image above we will output two atlases, one at full size called "name@4x" and another one at half the size called "name@2x"

You can find out more about all the packing settings here: Texture Packing - Spine User Guide: Output

I had the exact same question yesterday.
When you change the scale in the export settings, it will only reduce the quality of your export but the scale will stay the same.
I don't know if you can resize while exporting from Spine while keeping the quality but i would love to know.

You can specify the scale of your skeleton at runtime when loading the JSON or .skel file. What runtime are you using?

Hello!
I was wondering, can't we have an option to specify the scale of the .skel at export?

Skeleton scale is always as it is from the project in the export.
Scale is applied at runtime by the skeleton binary or json loader.

Hello,

Could you please elaborate on your answer? Here is my use case:

1°) Let's say I am working on spine with assets either at 3000 * 3000 resolution, or 2000 * 2000 resolution.
2°) Let's say my game is designed for a resolution of 1000 * 1000.
3°) When I export my spine, I can scale down the texture using the scale option in the atlas export menu (either by a scale of 1/3 or 1/2), but the skeleton will not be scaled down.
4°) Now I want to import those spine using the runtime. How do I know which scale I should use to scale down the bones? There is nothing in the atlas nor in the skeleton data to tell me which scale was applied to the textures.

Now I have several options:

• I save the atlas export scale somehow and pass it myself to my runtime to load the skeleton with the right scale.
• I scale the root bone by the atlas scale just for the import, then put it back.

None of these solution are convenient, in the first case, I need to create a structure just for holding the scale somehow, and in the second, I am sure I will forgot to do both the manipulation one time, and I will mess my export.

So is it possible to have an option at export to also scale the skeleton data, or at least have a value (or an array of values) in the skeleton data at the top level that tells what was the exported texture size, so we can use this value in the runtime?

The resolution of your textures is independent of the scale of your skeleton. Consider this use case:

You have a mobile game that should work on tiny screens and tablets. On tiny screens, you want to use smaller versions of the textures, on big screens, you want to use the higher resolution versions. Now, how do you achieve that if on export you scale the skeleton down to whatever texture resolution/scale you've chosen? You'd have to export one skeleton/atlas pair for each device type you target. It would also mean you game code would all of a sudden use different coordinate systems depending on the device type. That's not good.

Instead, Spine promotes the use of a fixed coordinate system for the game code, within which the skeleton is positioned and scaled. Separately from that, you can export as many different atlases at various resolution break points as you want. This way, your game code stays the same regardless of the device resolution, while you can use low-res textures on low-end devices, and hig-res textures on high-end devices.

Well, you have a point there.

Thanks for you quick answer!

The resolution of your textures is independent of the scale of your skeleton

I agree, but what I need is the other way around: the scale of my skeleton should be dependent on the resolution of my textures.

The way we design our game is a bit different. We use cocos2dx, with a DESIGN_WIDTH and a DESIGN_HEIGHT. We export our assets for this target resolution, and cocos scale the glView depending on the device resolution. We don't have several textures size for several devices (which means that on devices with a higher resolution than what we target, the textures are upscaled , while on the other side they are downscaled).

Thus we are only exporting textures for one target resolution (it simplifies the asset exporting process and project maintenance).

Now onto spine. We are working on different spine resolution (fx are worked in DESIGN_RESOLUTION size, while others animations are worked with 2*DESIGN_RESOLUTION size, for easing the animation process (animators don't like animating pixel jam)).

When we export our assets the fxs are thus exported with a texture scaling of 1.0, while the others animations are exported with a texture scaling of 0.5.

When loaded by the runtime, I have yet no way to know how to scale the spine skeleton to match our DESIGN_RESOLUTION (meaning scaling it either by 1 or by 2), because I can't easily access the scale that was set in the export of the texture.

What we are doing now is importing the spine at a scale of 1, then resizing it to our design resolution size using cocos2d nodes scaling, but it is not very good because it induces additional unneeded steps (spine runtime import will eventually upscale the textures by 2 to match our exported skeleton size, which will then get scaled down by 2 by cocos2d, which means that the gpu needs to handle 2*more pixels than if we just import the skeleton data with the right scale)

Please let me know if something is not clear, or if there is a more easy way to do it.

Thanks again!

I think the quickest and simplest solution to your specific problem is to have your artists set the scale of the root bone of the skeleton in the editor. That way the skeleton gets a uniform scale on export.

Thank you.

That was one of the possible solution we thought about. I guess we'll just have to be very careful not to forget it.

Just to note, what badlogic described is the recommended approach for building games, not just for using Spine. You say you develop your game using fixed world coordinates and cocos2dx scales your game as necessary to best fit the screen size. This is exactly what badlogic described. However, you say you will use just one atlas which will be scaled up or down. With badlogic's approach you choose an atlas size closest to the size of your on-screen game elements. Providing textures nearest to the screen resolution generally provides better results and uses less memory (often low resolution devices have less memory).

When we export our assets the fxs are thus exported with a texture scaling of 1.0, while the others animations are exported with a texture scaling of 0.5.

When loaded by the runtime, I have yet no way to know how to scale the spine skeleton to match our DESIGN_RESOLUTION

You say you choose the scaling used to export your textures, so obviously you know how much each has been scaled. While the information isn't in the texture atlas data, you certainly do have ways to know what scale was used. Eg, put it in the atlas file name or keep a CSV or text file that lists the scales for each texture.