Nick yazdı** warning ** I am not a native English speaker. Sometimes people may find my way of expressing my thought a little rude. I want you to know that it is not what I want to achieve in case you get bad feeling reading the post.
Understood, no worries. It is a good reminder though that text can be difficult to judge tone. We should all assume the best intentions!
Nick yazdıI don't think I can change your mind.
I have to make a lot of decisions and (usually!) have put a lot of thought into them. I do care about what you want, if I didn't I wouldn't bother explaining why I think as I do. Consider my explanations not as being defensive, but as being open so you can address whatever is preventing me from agreeing. I am always open to being convinced something is better.
Don't give up! Focus on the problem you are having, not necessarily a particular solution you think is best, and we'll find a way to make it nice.
Nick yazdıI am talking about keeping things simple while you are talking about functionality and making things flexible from a programmer stand point.
What we provide has to work for everyone in every conceivable situation, so we aim for flexible first, then easy to use next, in the order of the most common use cases.
The runtimes are really for programmers. Some game toolkits allow doing a lot with a UI, but at some point code will need to be written. Still, I hear what you are saying, that you are doing something common and it's not as easy as you'd like.
Nick yazdıWe all know it is not good to have things duplicated but for productivity, it is a trade off, a good deal and is not a problem at all.
The skeleton data is designed to be loaded once, then shared across multiple skeleton instances. Duplicating skeletons goes against this and isn't how we designed it to be used. I don't want to throw the design out the window as a workaround for how images are packed.
Giving it some more thought, it could be that we need more powerful texture packing. Here's two ideas:
1) Maybe when you pack a skin folder, you could give the texture packer a prefix for the region names. From my examples above, if you are packing images/skin1 you could specify skin1/ as a prefix, resulting in region names like skin1/head/red.png.
2) Or, when the texture packer knows the Spine project, it could detect when packing a subfolder of a skeleton's images path and adjust the paths so they match what they were in Spine. In the above example, if images is the skeleton's images path, the packer would see the root of the input folder images/skin1 is under the images path and prefix skin1/ automatically. This seems pretty good, as you don't need to specify the prefix manually.
With that you can pack an atlas that contains only a subset of the Spine project's images, but still has names that match the attachments in Spine.
The next part is that you want to load skeleton data with an atlas that doesn't contain regions for every attachment. Currently AtlasAttachmentLoader throws an error, but we could add a setting so it just doesn't set a region in that case. That could show up as a checkbox in game toolkit UI.
What do you think?
