Space problems with graphics

I have a doubt:

Do I think metasprites to compose maps of my games, they occupy more or less space than if I think maps with NEStoolScreen and keep each screen with RLE?

Should you use Screen Tool to compress level data?

Depends on your data.

If there are lots of repeats, yes. If very few repeats? No.

Ok.

On the other hand, I'm testing and it seems that there is a limit of up to 64 metasprites in the same array to compose scenarios.

Is this possible?

Oh, you're talking about the "metasprite" tool in NES Screen Tool.

If the problem is, the "metasprite bank" has a max of 64 arrays. You can put each individual metasprite seperarately. Then the question is, how does your code find the correct metasprite? Each character could have an array of constant pointers to each of his metasprite animations.

No. The problem is already solved after passing me all afternoon yesterday to investigate, but you explained:

I need to do various backgrounds to form a map. These background are static. There is no scroll, it is therefore relatively easy.

To save space, instead of creating background to the gross with NEStoolScreen, what I do is to create a background with all the tiles I need, etc... to create metatiles. With this background, I do two things:
- The first is to save it in BMP format and then the program Tiled, I think maps. These maps return me an array that identifies in that position must go every metatile.
- Secondly the background of metatiles which had been created in NEStoolScreen save it the format .h uncompressed, which returns an array of metatiles to me but disordered. Then with a small tool that I've done in javascript transformed this array in another that has ordered the metatiles of 16x16 as I need them.

The problem that had yesterday was that they left me in total about 104 metatiles, and only read me the first 64. Solve it transforming the variables for use in INT format. They were previously as CHAR.

Now work.