Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Allow different file types for atlases #137

Open
ChristianPervoelz opened this issue Nov 1, 2022 · 6 comments
Open

Feature Request: Allow different file types for atlases #137

ChristianPervoelz opened this issue Nov 1, 2022 · 6 comments

Comments

@ChristianPervoelz
Copy link

As of now there is one global setting to define the file type the atlases of a project are stored to, but sometimes it would be useful to have a different type than the globally defined one.

For example:
I have a project with several atlases containing a bunch of small sprites. They are all packed using png and some kind of compression.
But the project also has an atlas with quite some really big images. Packing them as png is ok, but using jpeg could create files with 20% of the size of a png with a still reasonable quality.
(When developing for mobile, it is big difference whether you have 100MB of assets or just 20!)

Request
Texture packer could have an option allowing to specify the file type (and the according settings) per atlas of a project. If there is no specific setting the project is used.

Remark
I know I could use different projects for different atlases, but nonetheless it could be quite useful.

@metaphore
Copy link
Member

Hi @ChristianPervoelz and thanks for the suggestion!
I actually have something similar in mind, but wasn't sure there's a demand for such feature. I generally like the approach of having "global" export setting, but also an option to use a different configuration per atlas would be handy.

I'll keep it open for a discussion and add the task to a backlog.

@Frosty-J
Copy link
Contributor

Frosty-J commented Nov 1, 2022

I don't find the JPEG compression in this very good. Do we really just get that quality slider with 10 steps? This is not an attack on gdx-texture-packer-gui, as in my view a texture packer only needs to be good at packing textures.

I often just use GIMP, which has 101 quality steps and 4 chroma subsampling options, but MozJPEG has more efficient compression than most software, and more options (none of which I find particularly useful, but they're there if you're into that) so I like to use that for anything serious.

Bringing another tool into the mix will be a necessity (unless there are features I hadn't noticed) if you want to separate your alpha channel into a separate greyscale image (due to JPEG's lack of alpha channel support) and I'm not sure texture-packer has anything for aligning your sprites to MCU (macroblock) boundaries.

While I wouldn't personally use the feature, I think it would be good to have all those global settings to be on a per-pack basis instead.

@metaphore
Copy link
Member

I don't think JPEG intended to be anything serious in the original libGDX code in the first place, but it's there just for those who wish to go down that path and thus it sure needs to be supported.
All in all it's just a question of prioritization, cuz I obviously can't dig deep into all the possible file types and compressions, and JPEG is the one I'd improve the last in favor of anything with GPU compression and generally less quality loss options.

@ChristianPervoelz
Copy link
Author

I'm not a fan of JPEG either, but seriously... does it take us anywhere discussing the pros and cons of JPEG and its support in libGDX/Texture Packer in this issue?

@metaphore big thanks for this app and for considering the new option as a feature.

@metaphore
Copy link
Member

There's actually nothing wrong about taking JPEG seriously at all. I mean from my experience it's not the best suit for atlases, but I only can judge from my very subjective view. This project has a long story of developing things "blindly" and not assessing any real demand from the community, cuz I really have no tool for that. So any input and constructive discussion is highly appreciated.

@metaphore
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants