It is currently Sun Dec 17, 2017 5:15 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Thu Jul 14, 2016 10:03 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
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().

Quote:
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.

Quote:
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. :)

Quote:
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 10:17 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 10:19 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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).


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 10:49 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 12:26 pm 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
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:
Attachment:
map2.7z [468 Bytes]
Downloaded 37 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)


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 1:25 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
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?


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 1:56 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
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:
Attachment:
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 2:31 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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).


Top
 Profile  
 
PostPosted: Thu Jul 14, 2016 2:58 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6535
Location: Seattle
I've been arbitrarily using .chr2, .chr4, and .chr8 to hold SNES-encoded bitplanes of the corresponding depth.


Top
 Profile  
 
PostPosted: Fri Jul 15, 2016 12:29 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
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.
Attachment:
direct-select-2048.png
direct-select-2048.png [ 700 Bytes | Viewed 1300 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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sat Jul 16, 2016 2:49 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
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)


Top
 Profile  
 
PostPosted: Sat Jul 16, 2016 1:52 pm 
Offline

Joined: Wed Jul 09, 2008 8:46 pm
Posts: 242
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.


Top
 Profile  
 
PostPosted: Sun Jul 17, 2016 5:27 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group