It took a long time and takes the fun out of a job that TexturePacker is supposed to be automating and simplifying for me. And it is not possible in Godot to re-arrange tiles easily, so the only option left was to manually rename most tile graphics, and then re-import for testing. It is just too much work and very cumbersome to be renaming that many tiles. Renaming all of 128 tiles to match the requirements took a whole day, including fixing mistakes. The code by the developer (who uses Godot) required the various types of tiles to be grouped in specific locations for automatic randomized level generation. Today I had to hand over a fairly large tilemap to the developer of a game we are working on. It would have saved me quite some time today if simple mouse-based re-ordering would have been possible in TexturePacker Pro. This is my first post here, and I am posting here to ask you to reconsider this. For big sprite sheets I understand the point of memory gain, but for small sheets it is sometime also good to keep it simple
TEXTURE PACKER MANUAL
I think it is not very difficult, but in some cases this manual sort might be for some users very useful. ) I hoped someone would have managed to get something functional as it does not remove the main feature of texture packer but give some additional features. So when sprites are split in a smart way I basically can’t find my elements very easily.Īdditionally, some sprites are very similar to other because of color.Īfter 3y investigation I would have except something might have been doneĬf.
TEXTURE PACKER SOFTWARE
The texture packer software helps me to organize 300 sprites, but some sorts appear to be very random and I have 10-20 tile fields to sort. However there are many reasons, the first one is to simplify the use tile mapper editors and autofill options. (e.g.Tiled software)įor this reason some sprite sheets are given like a squared shape as following: and it makes life easier. I understand the point of texture packer: to create very useful sprite sheets and improve memory usage.
0 kommentar(er)
