Slydog my code folder is full of failed experiments. This is a rare one that seems to have paid off...so far. I haven't tested it on all my devices yet. Tomorrow I will.
just remove the last 2 calls?
I'm fairly sure removing those two calls will work as intended. Ultimately the test will be to see if the generated PNG files can be opened in browsers/image editors, etc. It should work though, in theory, since the palette is only strictly necessary for images with indexed color. I've seen source code that leaves out those two lines.
Example from a cross-platform PNG library - file writepng.c :-
/* Set the palette if there is one.
* REQUIRED for indexed-color images. */
if (img->depth <= 8)
{
int i;
palette = (png_colorp) png_malloc(png_ptr,
256 * sizeof (png_color));
/* Set palette colors. */
for (i=0; i < img->cmap_size; ++i)
{
palette[i].red = img->cmap[i].red;
palette[i].green = img->cmap[i].green;
palette[i].blue = img->cmap[i].blue;
/* palette[i].alpha = 256 - img->cmap[i].alpha; */
}
png_set_PLTE(png_ptr, info_ptr, palette, img->cmap_size);
}
So, should work.
ok, don´t understand too much, but I suppose someone in the forum put an example... 
I will do that soon. I need to improve how the files are saved. Currently the routine saves two files where only one should be needed. I'll update the code and post a better documented example...probably tomorrow.
- If graphics is set to 16 or 15bit, often the texture would loaded as 16bit, and hence content would been changed. Howover since I seen its using memory and not graphics memory, I think its dont happens here?
I've just tested this: GLBasic will load PNGs with 256 indexed color, RGBA color with 8bit channels and RGBA with 16bit channels just fine. All work (on the PC at the least). However,
when you save a PNG file in GLBasic it will always save as RGBA with 8bit channels. Because of this you'll never compress a file with the PNGZ code that will be treated as 16bit and look odd. Even if that were possible there would be a way to work with it.
