Your tile size is odd with 16x15px and only the last column also has a right border, which means it will not align with the other tiles.
If it was meant as 15x14px with 1px spacing on all sides, then the last column is only 14x14x.
Everybody who wants to use it with tiles of 2^n x 2^n has to edit or stretch them.
Some tiles have color differences so minimal that I can barely see them on higher zoom (colum, row; starting with 0): 0,1; 2,1; 3,1; 4,1; 1,2
The PNG usese 59 unique colors (irrelevant fun fact)
2,1 (the orange screen?) looks different from 3,1 and 4,1 like it was colorized with an color shift effect:
the white is slightly orange while the other two have pure white
the orange (#FF9E00) is slightly different from 2,2 and 3,4 (#FF9500)
Much of that is just my pixelart nitpickiness, but it slightly influences how well the PNG can be compressed. If colors are the same, the compression algorithm can utilize that, but if they only differ a bit they have to be treated as different colors. There are also tools that can reduce the size of PNGs to some extend. (Not really like they get used much here on OGA and I usually don't use them either) Here examples with standard settings of optipng, pngcrush and pngquant as well as my demake which has a de facto reduction in color but more pixels:$ ls -l costume*.png
-rw-r--r-- 1 user users 873 14. Nov 20:28 costume1_nes_demake.png
-rw-r--r-- 1 user users 1078 15. Nov 00:31 costume1optipng.png
-rw-r--r-- 1 user users 2037 14. Nov 20:04 costume1.png
-rw-r--r-- 1 user users 1205 15. Nov 00:30 costume1pngcrush.png
-rw-r--r-- 1 user users 1078 15. Nov 00:30 costume1pngquant.png
$ file costume*.png
costume1_nes_demake.png: PNG image data, 80 x 64, 8-bit colormap, non-interlaced
costume1optipng.png: PNG image data, 80 x 61, 8-bit colormap, non-interlaced
costume1.png: PNG image data, 80 x 61, 8-bit/color RGBA, non-interlaced
costume1pngcrush.png: PNG image data, 80 x 61, 8-bit/color RGBA, non-interlaced
costume1pngquant.png: PNG image data, 80 x 61, 8-bit colormap, non-interlacedThe numbers like 2037 are size in Bytes. That means costume1optipng.png is 53% the size of costume1.png. costume1_nes_demake.png only 43% Not things you have to change, but just because you said it was your first ever.
But I honestlly think what'd be more useful for OGA is a cc0 AI for style transfer or maybe style normalization. We have a lot of assets here, but it can be a challenge to mash them together and still have a consistent style.
it would be a cool project to train your own dataset using only cc0 assets.
There are some who try that, but the results don't look great so far. It's possible that this can change if techniques etc develop further and you can get better outputs with less input or something like that. You can also use public domain, but that's sometimes tricky becaus the rules differ from country to country. PD also results in a less trendy style since the majority is probably very old drawings (mona lisa for example) or photos that are black and white or don't reach modern color quality.
Mitsua Diffusion CC0 claims to be trained from scratch using only public domain/CC0 or copyright images with permission for use
Mitsua Diffusion One claims to be trained from scratch using only public domain/CC0 or copyright images with permission for use
They list the sources roughly, but none of them published the whole training data. At least Mitsua published the one that is partially licensed.
There is also the newer Mitsua Likes, but the model license is more restrictive NC.
There is also another issue. Wrongfully licensed artworks are a thing. There is pirated stuff that gets released under various CC licenses because the uploader doesn't care. Or remixes wher, at least to me, it's not clear if they really had the right to do that, but I see that rather CC music using unfree vocal samples.
I just loaded this into pixelorama to play around with it's spritesheet features and I noticed that the shadow on the left-facing heads for poking and shooting are wrong for man_olive. Their head is a mirrored version of the right-facing head, but in contrast to the rest of the body they shouldn't be just mirrored. I didn't check how it is for other spritesheets.
That would load the palette into the third subpalette and share the first two colors of all palettes. Default colors per subpalette is 4.
It would load the firts two colors of the given palette into the first two colors of the PNG palette and then the other two into 7th and 8th (3rd and 4th of the third subpalette). Every subpalette has two unique colors in this case.
The origin of shared colors is NES, which shares the first color of all palettes, but also the first sprite color being transparent on NES and Game Boy. Doing it like this instead of duplicating the color should improve PNG compression a bit, since especially sprites have sometimes complete rows filled with transparent.
I'm doing a lot with palettes right now since I try to create a tileset that works with black and white (Arduboy), four color grayscale (Game Boy), two colors per 8x8 (ZX Spectrum) and four colors per 8x8 (NES, MSX). That makes palettes even more complicated since now I'll also have duplicate subpalettes.
Next will probably be a tool to modify indexed PNGs:
check if tiles really only use one subpalette
autofix tiles if it's clear which palette shoud be used, which is the case when the colors are basically right but one was taken from the wrong subpalette
change subpalette of specified tile
swap positions of subpalettes and adjust the indices accordingly (maybe with multiple palettes)
merge duplicate subpalettes (maybe with multiple palettes loaded)
split images
merge images and their subpalettes (maybe with multiple palettes per image)
convert from/to subpalettes with shared colors (maybe with multiple palettes)
check if PNG's palette only uses colors that are in a .gpl palette
check if metatiles don't use more than N colors, even if they are from different subpalettes
Maybe even more simple changes like tile rearrangement, sprite frame duplication and stuff like that. Afaik there isn't really any tool that can do such stuff. Indexed images are quite niche and you'd usually do such stuff with imagemagick, but imagemagick always destroys palettes.
Edit:
A first version can check the subpalettes with specified tile dimensions, colors per subpalette and amount of shared colors between subpalettes.
It wil print stuff like "Tile 1x5 has 25 pixel(s) with colors from wrong subpalette(s)!"
Now it can also check if a metatile does not use too many colors. (RGB not palette indices)
NES can only have palettes per 16x16 metatile and not for every 8x8 tile ... unless a special chip is used. So far I ignored that restriction. I'm not sure if this could have any general use, since I mostly need it because my palette is more for switching systems. Maybe for checking that colors for metatiles don't get too out of hand.
Feedback from that edit:
2,1 (the orange screen?) looks different from 3,1 and 4,1 like it was colorized with an color shift effect:
Much of that is just my pixelart nitpickiness, but it slightly influences how well the PNG can be compressed. If colors are the same, the compression algorithm can utilize that, but if they only differ a bit they have to be treated as different colors. There are also tools that can reduce the size of PNGs to some extend. (Not really like they get used much here on OGA and I usually don't use them either) Here examples with standard settings of optipng, pngcrush and pngquant as well as my demake which has a de facto reduction in color but more pixels:$ ls -l costume*.png
-rw-r--r-- 1 user users 873 14. Nov 20:28 costume1_nes_demake.png
-rw-r--r-- 1 user users 1078 15. Nov 00:31 costume1optipng.png
-rw-r--r-- 1 user users 2037 14. Nov 20:04 costume1.png
-rw-r--r-- 1 user users 1205 15. Nov 00:30 costume1pngcrush.png
-rw-r--r-- 1 user users 1078 15. Nov 00:30 costume1pngquant.png
$ file costume*.png
costume1_nes_demake.png: PNG image data, 80 x 64, 8-bit colormap, non-interlaced
costume1optipng.png: PNG image data, 80 x 61, 8-bit colormap, non-interlaced
costume1.png: PNG image data, 80 x 61, 8-bit/color RGBA, non-interlaced
costume1pngcrush.png: PNG image data, 80 x 61, 8-bit/color RGBA, non-interlaced
costume1pngquant.png: PNG image data, 80 x 61, 8-bit colormap, non-interlacedThe numbers like 2037 are size in Bytes. That means costume1optipng.png is 53% the size of costume1.png. costume1_nes_demake.png only 43% Not things you have to change, but just because you said it was your first ever.
Congratulations.
Is this basically meant as a low-res texture for Minecraft/Voxelibre?
A quick NES-demake (palette, 16x16 tiles and not more than black + 3 colors per tile) for no apparant reason.
I copied that error in my names, but Sara is written without H
(First was: https://opengameart.org/content/sara-wizard)
Not Sara, but you could try one of these heads maybe:
Editorial OGA <3 Sarah Publishing House
If you happen to make a game remix of this one day (or if I do):
Should be possible to make fake games with assets from here, but physical games are also somewhat outdated at this point.
Looks like Mitsua Likes has published a few non-CC0 datasets, which are based on cc0 assets. So that could probably used for training. https://huggingface.co/collections/Mitsua/mitsua-likes-dataset
But I honestlly think what'd be more useful for OGA is a cc0 AI for style transfer or maybe style normalization. We have a lot of assets here, but it can be a challenge to mash them together and still have a consistent style.
There are some who try that, but the results don't look great so far. It's possible that this can change if techniques etc develop further and you can get better outputs with less input or something like that. You can also use public domain, but that's sometimes tricky becaus the rules differ from country to country. PD also results in a less trendy style since the majority is probably very old drawings (mona lisa for example) or photos that are black and white or don't reach modern color quality.
They list the sources roughly, but none of them published the whole training data. At least Mitsua published the one that is partially licensed.
There is also the newer Mitsua Likes, but the model license is more restrictive NC.
There is also another issue. Wrongfully licensed artworks are a thing. There is pirated stuff that gets released under various CC licenses because the uploader doesn't care. Or remixes wher, at least to me, it's not clear if they really had the right to do that, but I see that rather CC music using unfree vocal samples.
I just loaded this into pixelorama to play around with it's spritesheet features and I noticed that the shadow on the left-facing heads for poking and shooting are wrong for man_olive. Their head is a mirrored version of the right-facing head, but in contrast to the rest of the body they shouldn't be just mirrored. I didn't check how it is for other spritesheets.
There is a remix with textures: https://opengameart.org/content/3d-dungeon-torture-devices
You forgot https://opengameart.org/content/tiny-16-basic-add-ons
I'm back to this and updated https://github.com/basxto/loadgpl. I now support subpalettes and shared colors:
"./loadgpl.py src/tileset/zxtileset_cblack.png src/palette/dmg_basic.gpl tileset/zxtileset_cblack_dmg.png -u3 -s2"
That would load the palette into the third subpalette and share the first two colors of all palettes. Default colors per subpalette is 4.
It would load the firts two colors of the given palette into the first two colors of the PNG palette and then the other two into 7th and 8th (3rd and 4th of the third subpalette). Every subpalette has two unique colors in this case.
The origin of shared colors is NES, which shares the first color of all palettes, but also the first sprite color being transparent on NES and Game Boy. Doing it like this instead of duplicating the color should improve PNG compression a bit, since especially sprites have sometimes complete rows filled with transparent.
I'm doing a lot with palettes right now since I try to create a tileset that works with black and white (Arduboy), four color grayscale (Game Boy), two colors per 8x8 (ZX Spectrum) and four colors per 8x8 (NES, MSX). That makes palettes even more complicated since now I'll also have duplicate subpalettes.
Next will probably be a tool to modify indexed PNGs:
Maybe even more simple changes like tile rearrangement, sprite frame duplication and stuff like that. Afaik there isn't really any tool that can do such stuff. Indexed images are quite niche and you'd usually do such stuff with imagemagick, but imagemagick always destroys palettes.
Edit:
A first version can check the subpalettes with specified tile dimensions, colors per subpalette and amount of shared colors between subpalettes.
It wil print stuff like "Tile 1x5 has 25 pixel(s) with colors from wrong subpalette(s)!"
https://codeberg.org/basxto/palgic
Edit2:
Now it can also check if a metatile does not use too many colors. (RGB not palette indices)
NES can only have palettes per 16x16 metatile and not for every 8x8 tile ... unless a special chip is used. So far I ignored that restriction. I'm not sure if this could have any general use, since I mostly need it because my palette is more for switching systems. Maybe for checking that colors for metatiles don't get too out of hand.
Pages