Hmm, looks like tostring() was deprecated in a later version of Pillow. (Seems very strange of them to break the interface like this, I hope they had a good reason!) I guess I'll add a check to see if tobytes() exists, and if not, fall back to tostring().Ramsis wrote:Python initially complained about line 92, prompting me to change tile.tostring() to tile.tobytes() (possibly because I have Python 3 installed alongside Python 2?). After making the change, the script ran smoothly.
Yeah, snes-tile-tool doesn't import screen-by-screen. I guess that would be a good option to have. Probably the "screen" size should be 32x32 tiles so it'd work with 16x16 px tiles as well.I have a 512×256 file which is used with a 64×32 tile map. I had to do the following in order to get a tile map that I can DMA straight to VRAM (apart from adding palette bits, but never mind for now): ...
No big deal of course -- apparently the tool I used previously (gfx2snes) processes each 256×256 "screen" in your image as if they were aligned vertically.
Hmm, it works here: python snes-tile-tool.py -i map.bmp -b 8 -s 8x8 -m7 -Od -o map produces a 512 byte palette file. Hopefully it's not another case of Pillow incompatibility.Mode 7 palette output seems to be broken, as I got a palette file that was some 680-odd bytes in size when I tried to convert this file. Or is this because of my Python 3 installation?
Note that at the moment it doesn't generate the extra 3 bits in the nametable data, those are always 0. Doesn't make a difference for Mode 7 of course.This tool even supports direct color mode, and it works like a treat! Again, wow, and a big thumbs-up!
...
BTW, are there any "standardized" file extensions for SNES graphics files? In NES circles .chr/.nam/.pal is pretty standard, so I went with those. But I noticed that YY-CHR defaults to 2 bpp NES graphic format whenever .chr files are opened... It also auto-opens the (incompatible) .pal file, which is somewhat annoying.