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

DXT -> BCN? #1271

Closed
Josh015 opened this issue Jun 30, 2020 · 4 comments
Closed

DXT -> BCN? #1271

Josh015 opened this issue Jun 30, 2020 · 4 comments

Comments

@Josh015
Copy link
Contributor

Josh015 commented Jun 30, 2020

I was just wondering if it would be a good idea to switch from Dxt* naming scheme to Bcn* in order to match Microsoft? Also, are there any plans to support BC4 and BC5 since L8 and La8 would map well to them?

@fintelia
Copy link
Contributor

My preference would be to create a new image-bcn crate and move all the dxt encoding/decoding to there. We could then deprecate and eventually remove all the Dxt* code from image and retain only support for the DDS format.

I don't personally have plans to add support for other block compression formats, but PRs are welcome!

@HeroicKatora
Copy link
Member

HeroicKatora commented Jun 30, 2020

Starting the revision from a clean slate in a new crate sounds preferrable for me as well. Note it's possible retro-fit the current implementation to instead use a crate. The only implementation that we (sadly) can't readily change is the DXTVariant enum as it wasn't defined to be non-exhaustive (quite an oversight tbh). But we could add a new enum instead and provide a converter from the old. That should leave many, if not all, interfaces intact. The DdsEncoder is entirely opaque as well. We can additionally define type aliases to rename everything to the Bcn* names, also without any major breakage (sadly we can't do the same for enum variants).

A new crate could expose many more internals, as long as it's not a public dependency of image the need for a stable interface isn't as large. It could experiment a lot more as well. At some point when format support gets detailed enough, we move them out into separate crates. For example, this happened with png, gif, tiff.

@Waelwindows
Copy link

I think it's better to map BC5 to R8G8, because not all textures use the "green" channel as alpha. e.g. normal maps

@fintelia
Copy link
Contributor

fintelia commented Jul 8, 2020

@Waelwindows thanks for catching that! It probably isn't worth adding R8G8 as a format just to handle BC5, given that for decoder output La8 actually just means "a two channel format where even bytes are one channel and odd bytes the other". But you are right that the documentation should say that clearly somewhere so that users don't get confused

@fintelia fintelia closed this as not planned Won't fix, can't repro, duplicate, stale Mar 10, 2024
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

4 participants