Suggested features of a new gfx converter

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Suggested features of a new gfx converter

Post by thefox »

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.
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().
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.
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.
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?
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. :)
This tool even supports direct color mode, and it works like a treat! Again, wow, and a big thumbs-up! :D
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.

...

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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Suggested features of a new gfx converter

Post by thefox »

tepples wrote:It's possible, so long as all 1-character options use one hyphen and all long options use two. See the paragraph beginning "Several short options can be joined together" in the argparse reference.
Thanks.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Suggested features of a new gfx converter

Post by koitsu »

thefox wrote: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.
There's no standard or even "commonplace". The official developers manual uses the following terms though:

* BG SC data ("background screen data") refers to "screen layout", i.e. nametable data on the NES
* CHR data refers to actual tile data, i.e. pattern table data on NES
* OBJ data (also "OBJ character data") refers to sprite data, i.e. OAM data on the NES

In the homebrew community, the most common extensions I saw used were .bin (this could be used for any of the above 3), and/or .map (used for BG SC data). In the few commercial games sources I've seen, it just varied based on whatever internal tools were made + naming conventions there; but .map was a common one for BG SC data, but for actual CHR data, a lot of things put CHR in the actual base filename (e.x. "FOOCHR16.BIN" or the like).
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Suggested features of a new gfx converter

Post by tepples »

Given that so many custom chips in the Super NES console and Game Paks are prefixed with "S-", I hereby propose these:
  • .schr (S-character) for 4-bit tiles used in sprites and background modes 1, 2, 5, and 6, as well as TurboGrafx-16 backgrounds
  • .snam (S-nametable) for mode 0-6 maps
I've asked about 2-bit tiles elsewhere. And someone who still hangs out on gbadev.org might ask what extension they use for rot/scale tiles and maps, which have the same format as Super NES mode 7 tiles and maps.
User avatar
Ramsis
Posts: 341
Joined: Sun Jul 01, 2012 6:44 am
Location: Lion's den :3
Contact:

Re: Suggested features of a new gfx converter

Post by Ramsis »

thefox wrote: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. :)
Hmmm ... strange. This is what I get:
map2.7z
(468 Bytes) Downloaded 169 times
thefox wrote:Note that at the moment it doesn't generate the extra 3 bits in the nametable data, those are always 0.
Can't wait for you adding support for those! ^^
thefox wrote: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.
pcx2snes/gfx2snes output *.pic/*.map/*.pal files, which is what I'm kinda used to. But as long as it's clear what's what, I don't really care about file extensions. :)
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

Re: Suggested features of a new gfx converter

Post by 93143 »

Neviksti's SNES starter kit uses .pic, .map, and .clr, so that's what I've been using.

And the graphics converter in the kit is pcx2snes. Are you sure about that .pal thing?
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Suggested features of a new gfx converter

Post by thefox »

Ramsis wrote:
thefox wrote: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. :)
Hmmm ... strange. This is what I get:
map2.7z
I updated my Pillow to 3.3.0 and it started exhibiting the same bug. Should be fixed now. (I was using image.palette.palette, which was probably an implementation detail, should have used getpalette()).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Suggested features of a new gfx converter

Post by Sik »

koitsu wrote:In the homebrew community, the most common extensions I saw used were .bin (this could be used for any of the above 3), and/or .map (used for BG SC data). In the few commercial games sources I've seen, it just varied based on whatever internal tools were made + naming conventions there; but .map was a common one for BG SC data, but for actual CHR data, a lot of things put CHR in the actual base filename (e.x. "FOOCHR16.BIN" or the like).
I've been using stuff like .4bpp and .1bpp. Guaranteed that no existing tool will stupidly attempt to use it like somethng else =P

EDIT:
tepples wrote:Given that so many custom chips in the Super NES console and Game Paks are prefixed with "S-", I hereby propose these:
  • .schr (S-character) for 4-bit tiles used in sprites and background modes 1, 2, 5, and 6, as well as TurboGrafx-16 backgrounds
  • .snam (S-nametable) for mode 0-6 maps
That could work too.

Also if somebody wants to save any random generic binary, I'd suggest to use .blob (since some stuff uses .bin for ROM images).
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Suggested features of a new gfx converter

Post by lidnariq »

I've been arbitrarily using .chr2, .chr4, and .chr8 to hold SNES-encoded bitplanes of the corresponding depth.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Suggested features of a new gfx converter

Post by thefox »

I added support for the 3 LSB bits in the screen data for Direct Select. Kind of annoying to test, hopefully it works fine. I used this image to test it, the results seemed sensible at least.
direct-select-2048.png
direct-select-2048.png (700 Bytes) Viewed 4732 times
I also added support for screen-by-screen import (-w), which makes the data layout compatible with the different screen size settings in $2107..$210A.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
Ramsis
Posts: 341
Joined: Sun Jul 01, 2012 6:44 am
Location: Lion's den :3
Contact:

Re: Suggested features of a new gfx converter

Post by Ramsis »

93143 wrote:Neviksti's SNES starter kit uses .pic, .map, and .clr, so that's what I've been using.

And the graphics converter in the kit is pcx2snes. Are you sure about that .pal thing?
You're absolutely right about pcx2snes. It's only gfx2snes outputs .PAL palette files.
thefox wrote:I added support for the 3 LSB bits in the screen data for Direct Select. Kind of annoying to test, hopefully it works fine. I used this image to test it, the results seemed sensible at least.
Awesome! 8-)
thefox wrote:I also added support for screen-by-screen import (-w), which makes the data layout compatible with the different screen size settings in $2107..$210A.
Fantastic, thanks a lot! :D I think it's about time to completely send *x2snes into retirement! :lol:

Now, if you still want to continue adding features to your tool, I'd be even more happy. *rawr* :mrgreen:
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)
KungFuFurby
Posts: 275
Joined: Wed Jul 09, 2008 8:46 pm

Re: Suggested features of a new gfx converter

Post by KungFuFurby »

That's one of the major things I could use, and since this is programmed in Python, it might give me less of a headache then when I tried gfx2snes with those endianness issues.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Suggested features of a new gfx converter

Post by thefox »

Yeah, I'm willing to still keep working on this, although the rate of progress might vary depending on how much time I spend playing around with SNES in general. (I don't want to develop features if I have no way to test them myself.)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Post Reply