Open fafling opened 3 years ago
This will be my next task in my todolist
I don't think there is an issue here. For my test I used the "8 bits TGA" demo and I put the brick in front of the Sonic image (more visual).
If we do : jo_sprite_add_tga("TEX", "BRK8.TGA", 0); // 0 means no transparency We have:
If we do : jo_sprite_add_tga("TEX", "BRK8.TGA", 1); // So the first color in the palette is transparent We have:
If we do : jo_sprite_add_tga("TEX", "BRK8.TGA", 2); // So the second color in the palette is transparent We have:
@fafling Hi, if you agree i will close this issue
Sorry but I don't agree that there's no issue.
In Sonic TGA texture, the area that surrounds Sonic uses index 0. Yet, you have to set the transparent_color parameter of jo_sprite_add_tga to 1 to make that TGA index 0 transparent. How can a user guess that transparent index has to be increased by 1 for that parameter ?
Where is it stated that "0 means no transparency" in jo_sprite_add_tga ? If that is the case, it is unintuitive to put such a flag in the transparent_color parameter, especially when 0 is the transparent index in Saturn.
Why does jo_tga_get_pixel always add 1 to 8 bit TGA pixels ? What does happen if the TGA texture uses index 255 for a non transparent color ? Does it become 0, hence being considered transparent by Saturn ?
If all this aims at allowing the use of a transparent TGA index different than 0, I think that when reading the TGA texture (and its palette), the transparent index and index 0 should be swapped, without modifying the other indexes.
Sorry but I don't agree that there's no issue.
In Sonic TGA texture, the area that surrounds Sonic uses index 0. Yet, you have to set the transparent_color parameter of jo_sprite_add_tga to 1 to make that TGA index 0 transparent. How can a user guess that transparent index has to be increased by 1 for that parameter ?
There are comments in examples, but I will add some info in the documentation Note: The value of JO_COLOR_Transparent is 0.
Where is it stated that "0 means no transparency" in jo_sprite_add_tga ? If that is the case, it is unintuitive to put such a flag in the transparent_color parameter, especially when 0 is the transparent index in Saturn.
From the beginning, if we put JO_COLOR_Transparent as transparent color for an image, it means that the image has no alpha component. When I start to implement 8 bits images with the same method (jo_sprite_add_tga) I used the same mecanics with JO_COLOR_Transparent, but because of its value, you have to add 1 to the index. Otherwise, I would have had to split the code in half with new methods for 8-bit images just because of that.
Why does jo_tga_get_pixel always add 1 to 8 bit TGA pixels ? What does happen if the TGA texture uses index 255 for a non transparent color ? Does it become 0, hence being considered transparent by Saturn ?
Yes, 0 means transparent by the saturn. that's why. In the image data, 1 means index 0 in the palette. You can use 255 as transparent color, but 8 bits TGA must be 255 colors max.
If all this aims at allowing the use of a transparent TGA index different than 0, I think that when reading the TGA texture (and its palette), the transparent index and index 0 should be swapped, without modifying the other indexes.
As it is, that documentation is incorrect :
Currently, the 8bits tga demo only enables transparent pixels on the Sonic sprite if its transparent color is set to 1 instead of 0.
If the bricks are drawn behind Sonic, they are completely overwritten if Sonic's transparent color is set at 0 :
The modified demo with Sonic transparent pixels working : demo - 8bits tga transparent color test.zip
This is due to 2 things in tga.c :