ROM Hack Unused tiles in NCGR/NCER data?

[Theou Aegis]

EDIT/UPDATE:
Am I right in assuming NCGR data must be read in blocks of at least 128 bytes per cell, so any cell of size 0 will have unused NCGR data up to 128 bytes (so an 8x8 cell would have 96 unused bytes, an 8x16 cell would have 64 unused bytes)?


When I organized tile dumps by hand, it was obvious that certain "blank" tiles were discarded. However, I don't understand how those tiles are marked in NCER data. Now while I'm aware Tinke can display and export the sprites just fine, for coding practice and just out of curiosity, I'm trying to write a batch sprite compiler - like, a program that will read through a directory of dumped data and create the files all at once. I thought I finally got a rudimentary code working - I tested on two slightly different sprites with acceptable results - but when I got to an NCGR that had unused tiles, it fell apart.

For example, consider Driscoll's portrait from Front Mission DS. The tile count according to the NCER file is 78 tiles, but the NCGR file has 80 tiles (8px by 8px). In the attached image, you can see a 32x16 section of solid pink tiles. Those aren't used in the image, and from what I can tell in the NCER file they're not even covered up by other tiles - if that was the case, then the NCER data would still have an 80 tile count, not 78. If you're wondering how I came up with the NCER's tile count, I added up all the cell bank sizes (e.g., 4x4 + 2x1 + 4x8).

The unused tiles are in the NCGR file from 0x02F0 to 0x032F.

Driscoll.NCER (cell bank data):
4B 42 45 43 A0 00 00 00 05 00 01 00 18 00 00 00
02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
06 00 1A 08 00 00 00 00 3F 00 4F 00 00 00 00 00
01 00 10 08 24 00 00 00 27 00 2F 00 08 00 20 00
01 00 13 08 2A 00 00 00 27 00 3F 00 08 00 30 00
00 00 00 08 30 00 00 00 00 00 00 00 00 00 00 00
00 00 00 08 30 00 00 00 00 00 00 00 00 00 00 00
28 00 00 40 00 00 08 80 00 80 01 00 40 40 10 80
03 00 48 40 30 00 05 00 28 80 30 80 06 00 00 80
10 C0 08 00 20 40 08 80 10 00 30 40 08 80 12 00

The underlined part is where I expected the blank tiles to be. If I read and programmed right, that should be a 16x8 section. I know the blank tiles don't belong to the next section because the next section fits perfectly into the image. I arranged the tiles by hand even, just to be sure it wasn't a coding error. Both my program and my manual attempt yielded the same result - except manually I could tell the tiles weren't used.

I'm sure there's something I overlooked while trying to read up on NCER formatting, but not sure what I missed, so I'm hoping someone here sees this and can point out my error.

 

[Auryn]

Hi Theou Aegis,
i don't know how much i can be helpful because i never really programmed anything that read data like that from the NCGR/NCER and it's been a while since i played around NDS images but there are maybe some little things you missed.
- The nice 02 at the beginning of the second line in the NCER, means that you have extendend data there (usually you will not have the 28 80 30 80 06 00 00 80 part of the bank).
- you have the 48 40 part that is unknow at least in the 3 documents that i know to be online that list the NCER format.
- I don't know if you need to load those amount of bytes from a NCGR but it will probably not work on this image because its a NCBR. The difference between the two is that the NCGR is always composed from 8x8 tiles but a NCBR, each tile can have a different size.
In fact if you check that image, it start with 3 tiles 16x16, then a 32x32 and then you have another 16x16 with your famous tiles on it. If i look a pic online of Discoll, there seem to be at least 1 pixel line below what you see inside that tile (actually inside your "unused" tiles) so i believe that those unused tiles are just padding for the 16x16 tile and are actually invisible/transparent in the game.

Here an image with in the top row set to 16x16 and the second row set to 32x32:

And here the image i saw online:

What strike me is that in my image, he look like he has the eye closed but in the image online, he has them open.

Anyway, the whole thing is probably used to make a 2-3 frame animation to make him blink and talk.

PS: if you have a working program, it would be interesting to have a copy, maybe i have a game that need exactly such a program

 

[Theou Aegis]

His eyes are open/closed depending on which OAM is currently drawn. In the NCGR dump I uploaded, you see two nearly complete 32x32 cells at the bottom. The first is his staring state, the second is his blinking state.

Since Tinke displays everything correctly, I've gone off the documentation associated with it online. I've also gone off of another one - I think it was at lowlines.com or something - and have been fiddling with the data trying to figure out which documentation I can trust. I'm surprised it's been so much work trying to find clear documentation on the file format.

Well I can draw most of the simple OAMs just fine now, as far as I can tell. I'll leave this topic as resolved for the time being. I stumbled upon another issue now I'll have to seek help on.

I'll upload the program if I ever get it working acceptably. I doubt that will happen, though.........

 

[rastsan]

it is the difference between one version of ncer and the next. you are dealing with a system that had its os develop remember. not uncommon to see a difference between version 1 of a file and version 5 of a file. fast6191 gave me the advice once to switch the y9 of the game with a different one - specific to using that type of compression (I was too lazy to take the time to properly do a asm hack and add it myself). example the compression used in the older was a4p the newer was at6p. They have documentation on two of them but not the one between (which is what I needed). Replacing the older games y9 (for compression) with the newer ones y9.bin helped immensely in getting a partial hack done. this might be what is confusing you. it not about a specific documentation its knowing that you may be dealing with one in between. (yes it was easier to use the at6p and similar files to replace the older at4p compressed ones)