so in the first image, what you can see is an animation of my character, this animation have 30 frames, in the second image, what you can see is the same 30 frames of the first one, but this time with each part of the body recoloured in a solid color, due to this color reduction, aseprite found similarities in the second export, and ignored 2 frames, well the problem is, I want both sprite sheets to have the same layout, is there a way to unmark that merge duplicates option?, and yes I want to keep the packed and trim cels on.
The only way to disable that option is to use a sheet type other than âPackedâ, unfortunately ): In your case, trimming and the sheet type By Rows should give good results that are nearly identical to the packed version.
Iâm not sure, but you may be able to get the results you want by making a version of your file that contains both versions on a layer each, and exporting the file once with âSplit Layersâ enabled.
@dacap This is a scenario where âMerge duplicatesâ is undesirable in a packed spritesheet, and we shouldnât have to work around it when the toggle is right there :'D Could we please have âmerge duplicatesâ optional even for packed spritesheets?
doing the âsplit layersâ I get this. idk if im doing it wrong cus it renders both in the same png
and about the âby rowsâ it works in this particular case, but iâm just showing one animation for simplicity, with all the animations the space wasted is huge compared to packed.
btw in this image, I did some changes, thats why this time the number of frames changed a little, I still get 20 frames out of 30 in the original one, but 22 in the other (this time I used gradient colors).
something to add, in the first post, I made a pixel check of every pixel in both sprites, to check if the silhouettes where the same, and they were identical (just checked if the pixel was transparent or solid on both), I didnt do that in this second one, cus my workflow is kinda weird so just so you know that maybe its something weird on my end that is causing some unexpected behavior.
Ah my apologies, split layers works differently from how I hoped, I thought it would make separate sheets of them spaced the same. In retrospect, why wouldnât it pack them normally :'D
Hi there! Actually the âPackedâ option might not be the solution in these case where the layout of two sprite sheets must be the same (if source images are not exactly the same, there is no guarantee that the order will be the same in Packed mode, details: sprite sheet images are saved in a hash table where the hash depends on the pixel values, this will change the order of the output anyway).
Possible solutions for packed sprite sheets:
- Use the corresponding JSON data of each sprite sheets (instead of using only the JSON data of the first sheet, you must use the JSON data generated for each sprite sheet)
- Use a script that matches the output of the second JSON with the first JSON. I could try to do it for you in case that you 100% need it and cannot use the second JSON data (e.g. we have a script that compare sprite sheets in the test repository, the code would be something similar to that)
Actually answering to myself, it could work, because we are not iterating the hash table (I donât have the code in my head at the moment, but just talking to myself right now).
Anyway, using âPackedâ mode and trying to uncheck âMerge Duplicatesâ is a bad practice and almost in all cases is hiding a bigger issue. For example, in this case we want to use the same layout of other sprite sheet but switching layers in the final result/layout, and just because âPackedâ without âMerge Duplicatesâ could work by chance doesnât mean that we should enable the option, it means that we need an extra option to achieve this specific use case.
1 Like
thanks for the help, It made me understand better the origin of my problems so I managed to fix it 
1 Like
+1 for this being an issue. I simply wanted to leverage the exact aseprite frame order after some out of aseprite manipulation of a packed file. Because this option is forced my export/reimport is no longer in the same order.
My files horizontal/vertical sprite size becomes an issue when going with the other options which could be solved in other ways, other programs, longer workflows. I understand why itâs being called a bad practice but the use case could be workflow vs optimization. Not sure that removes the need in dev environment where every project is unique.
In my case I was not looking for optimization. Just adding feedback to the topic I found through Google, sorry if there are more current topics on the issue!