How big can be the .chr file?

[kikutano]

Hello to everyone!
Another noob question about Nes Dev. I'm writing the frames for my animations on a .chr file so I need to know what's the max size of .chr to put my graphics into. So what's the size limit? What's the best way to put the entire graphics of the game into a chr ad read it?

Thanks!

[Kasumi]

The size limit depends on the mapper. If you're using NROM, you get exactly 512 8x8 tiles for the whole game. (8KB.)

On MMC3, you can use 256 KB of CHR. This is 16384 total tiles. There are other mappers with different limitations.

But regardless of how many tiles you have total, the NES can only see 512 at once. 256 of which are usually allocated for sprites. So if all your sprite animations take up more than 256 tiles, you need to write some way to manage them all.

[kikutano]

So I've to "unload" and "load" 512 tiles at time?

[calima]

Probably 256, as 512 might make for very complicated programming side.

[kikutano]

I see, thanks! Maybe I will try to put everything on 40kb game .

[tokumaru]

So I've to "unload" and "load" 512 tiles at time?

It really depends on the mapper. CNROM, one of the simplest mappers out there, allows you to have 4 8KB pages in total, and you can only swap all 512 tiles at once.

On the other extreme there are mappers like the MMC3, which divides the pattern tables into slots of 1 and 2KB, so you can swap smaller chunks at a time.

There's yet another option for managing graphics, which's CHR-RAM. Using RAM for your tiles means the cartridge doesn't have a separate chip where CHR data is stored, instead it has a RAM chip. The CHR data is then stored in the PRG chip, in whatever format the programmer wants, even compressed, and has to be manually copied to the CHR-RAM chip at run time. In this case, you have total freedom to replace tiles as you wish, but unlike with CHR-ROM, the switch isn't instantaneous, each byte has to be explicitly transferred by the CPU, consuming processing time.

[Sumez]

If you're planning on making graphics for a game, you should get your restrictions from whoever is programming it.
One thing is the innate limitations of the console as we can tell you about. But it really depends on the game design and how the engine is built. A lot of "business logic" stuff matters, like how palettes are distributed, which sprites are reserved for stuff like HUD/bullet/powerup/etc purposes, and how the game intends to dynamically load in new sprites/object types.