04-03-2017, 06:49 PM
(This post was last modified: 04-03-2017, 06:53 PM by gdkchan.
Edit Reason: fix typos
)
It's not a bug, you just need to remove the alpha channel entirely. I think you actually blended the image with a black background where the alpha still affects the blending.
If you have GIMP you can "fix" the texture doing this:
Open the texture, then go to Colors > Curves. On the dialog that will open select "Alpha" on the Channel drop down box, then click on the left black spot on the graph and drag it all the way to the top-left corner, and click on OK. You should now have the texture the way you want.
I've been working on a tool that should be a improvement to the original Ohana3ds, even through it's just bare bones for now, if you want to take a look: https://github.com/gdkchan/SPICA/commits/master
The original etc1 format doesn't support transparency yea. But the 3DS GPU does support through. On etc1 textures with alpha information, each 4x4 tile will use 8 bytes for alpha information (4 bits per tile, which is a 0-15 alpha range extended to 0-255), then it have 8 more bytes of the etc1 data. Also IIRC etc1 data on the 3DS in little endian, while the original etc1 tool uses big endian, and there's some tile swizzling, so the original tools aren't able to decode those. The GPU also have separate format for etc1 (without alpha) and etca4 (with alpha) textures, it isn't stored on the texture data itself but on a gpu command buffer (GPUREG_TEXUNITi_TYPE reg) on the bch file.
Example implementation in C: https://gist.github.com/smealum/8897237
If you have GIMP you can "fix" the texture doing this:
Open the texture, then go to Colors > Curves. On the dialog that will open select "Alpha" on the Channel drop down box, then click on the left black spot on the graph and drag it all the way to the top-left corner, and click on OK. You should now have the texture the way you want.
I've been working on a tool that should be a improvement to the original Ohana3ds, even through it's just bare bones for now, if you want to take a look: https://github.com/gdkchan/SPICA/commits/master
(04-02-2017, 03:20 AM)Bomb Bloke Wrote: The format is a lossy one which doesn't actually support transparency, as such - attempts to make it do so are often designed to be compatible with decoders that won't recognise them (so that you'll always get an otherwise correct representation of the image back, even if the output lacks alpha). Because of this, generic decoders which do support those methods have to likewise guess if they're in use (or be told), because there aren't any specific flags to indicate that they're there...
The original etc1 format doesn't support transparency yea. But the 3DS GPU does support through. On etc1 textures with alpha information, each 4x4 tile will use 8 bytes for alpha information (4 bits per tile, which is a 0-15 alpha range extended to 0-255), then it have 8 more bytes of the etc1 data. Also IIRC etc1 data on the 3DS in little endian, while the original etc1 tool uses big endian, and there's some tile swizzling, so the original tools aren't able to decode those. The GPU also have separate format for etc1 (without alpha) and etca4 (with alpha) textures, it isn't stored on the texture data itself but on a gpu command buffer (GPUREG_TEXUNITi_TYPE reg) on the bch file.
Example implementation in C: https://gist.github.com/smealum/8897237