How would you create NES sprites with GIMP ?

Post Reply New Topic

I mean would I have to make the Width and Height 8X8 for tiles, 8X16 for sprites or 16X16 for background tiles ?

If I'm not mistaken, I think tile editors or sprite editors have the same capabilities. Still wouldn't I have to take a note of the garbled tiles (like how NES game tiles are displayed out of order when your editing them ) and the addresses there stored at to have them display correctly in the final game ?

Which would be more convenient, A tile or sprite editor or the GIMP image manipulation program ?

You have to remember that NES/Famicom sprites, like the tiles, have a very restrictive format (for space reasons), and their exact color appearance in the game depends on the sprite palette currently loaded in the PPU and some other setting which determines which page of 4 colors out of the total 16 in the palette the sprite can possess*--don't remember if that's based on where the sprite is located or some other setting of the sprite. I don't know much about GIMP, but can GIMP produce the restrictive formats of the NES/Famicom sprites and tiles? If not, then tile/sprite editors are probably your best bet. You can also learn their very simple format and create them in a hex editor yourself, if you'd like. I don't remember their exact format, though I believe sprites and tiles have the same format, and there are docs on nesdev.com that teach it.

(What I do remember is that a single 8x8 sprite/tile is 16 bytes long and is stored in the CHR pages rather than the PRG pages and that a pair of bytes represents a horizontal line of the sprite/tile; bytes 0-7 and 8-15 refer to the same horizontal lines; for example, byte 0 and byte 8 refer to one line--can't remember if it's top or bottom,--byte 1 and byte 9 refer to the next, etc.; the bits for each line represent the actual pixels and allow for 4 different possible values for each pixel because 2 bits is devoted to each pixel, by way of 2 bytes referring to the same horizontal line which has a width of 8. Don't remember the details beyond that, though. You should check with a document on nesdev.com that goes into more detail. Of course, you can also, in the PPU, make sprites 8x16 as opposed to 8x8, but I don't remember how the sprites are read from the CHR pages when you set sprites to 8x16; documents are needed for that, too.)

*For both tiles and sprites, you insert a 16-color palette for each into the PPU. Each 16-color palette is divided into 4 pages of 4 colors and a single tile or sprite can only use 1 of the pages. For the tile, this means that it may use no more than 4 colors; for the sprite, because the first color is not used, as it instead represents a pixel that is to be transparent, you are actually limited to 3 colors. For tiles, if I recall correctly, you can set 16x16 areas which determine which page of the tile palette to use for the 8x8 tiles therein; I don't recall how to determine which page of the sprite palette to use for each sprite, however.

EDIT: Changed "group" of colors into "page" of colors.

EDIT 2: Whoops, was wrong about the number of colors tiles can use (after checking wiki of all places). Tiles can only use 3 colors as well, with the first "color" representing transparency against the current background color set in the PPU.

EDIT 3: To create 16x16 background tiles, you would group 4 8x8 tiles together when you load them in the PPU.

For more on 16x16 tiles, read up on tile maps, which is how they're implemented in the actual games. Basically, you have to keep in mind, the stuff the NES/Famicom provides you is really rudimentary and it takes a lot of tricks to be able to do stuff.

Heck, take split-screen scrolling. Without a mapping device that helps you pick the scanline to split the screen, you gotta do some magic with sprites--read the disassembly of SMB1 to see how they do it without a mapping device. Of course, virtually all games other than SMB1 use mapping devices because the data on the cartridges are too large to be loaded into the PRG-ROM and CHR-ROM all at once, so they have to use a mapping device which switches banks of data (anywhere from 8 kb size banks, basically in hexadecimal $2000 bytes long, to 16 kb size banks, $4000 bytes long, or often for CHR down to 4 kb size banks, $1000 bytes long) between the PRG-ROM and CHR-ROM and the PRG and CHR data stored in the cartridge.

MMC3 would be the most commonly used mapper, used for games like SMB3 and Kirby's Adventure, and it would make split-screen scrolling much less of a headache. There was also the MMC5 with more features, which was used in games like Castlevania, but it was a lot more expensive, so the MMC3 was often preferred.