-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
RGBA vs BGRA #32
Comments
I don't remember. If it fixes things for you, then it is probably what's required. You can verify by following the PNG decode path, which explicitly calls something related to bgra conversion (quite unnecessarily, but it's too ingrained into the code now). |
Thanks @wolfpld , I guess the question here is, is ETC internally BGRA? Ergo when we supply RGBA data, does ETCPAK convert it to BGRA and save it as such? I have a suspicion that us loading ETC data and then telling the GPU the data is RGBA, that this is actually where it goes wrong, not in saving, and us flipping the R and B channels on save just works around the issue. Is there any place to find good info on this? edit hmm, no thats probably not it, we're using |
There is only one way to decode the ETC data (i.e. transform the ETC binary stream into vec4 RGBA fields in shaders). Only input data to etcpak matters. |
Then i am happy that our changes in Godot are doing the right thing, does then indeed seem to be the input to |
Hi,
I'm trying to figure out an issue that we're having where it seems that the ETC compression routines are expecting BGRA input. I'm not ruling out that we are doing something wrong later on in the pipeline and assuming the decompressed image is in BGRA format and thus resulting in it displaying wrong.
Can you confirm whether
CompressEtc2Rgb
andCompressEtc2Rgba
expect data in BGRA format?Cheers,
Bas
The text was updated successfully, but these errors were encountered: