Display room mask

[gzip]

It would be nice to be able to see the room mask, something similar to the boxes.

I don't think the mask format is documented yet but I've picked it apart a bit. Let's use room 29 (under the house) as an example since it might be the most complicated mask. The RLE mask data for this room is stored in the rom at 225BA-22618 and gets decoded to ram at 6D7C. (In Mesen's Memory Viewer you can watch the bytes get accessed a column at a time as you walk through the screen.) Ignoring the rows of 0s, the mask is decoded as:

FC F0 C3 0F FC F0 03 00
78 E0 81 07 38 E0 00 00
30 C0 00 03 30 C0 00 00
30 C0 00 03 30 C0 00 00
30 C0 00 03 30 C0 00 00
30 C0 00 03 30 C0 00 00
30 C0 00 03 30 C0 00 00
38 E0 80 03 38 E0 00 00
38 E0 80 03 38 E0 00 00

This is bitmap data where each bit corresponds to a single tile, so a single byte covers a row of 8 tiles. A bit value of 1 = masked (background priority), and 0 = unmasked (sprite priority). We can visualize the bits in the above data to reveal the mask for a bunch of pillars under the house.

F    C      F    0      C    3      0    F      F    C      F    0      0    3      0    0
1111 1100   1111 0000   1100 0011   0000 1111   1111 1100   1111 0000   0000 0011   0000 0000

7    8      E    0      8    1      0    7      3    8      E    0      0    0      0    0
0111 1000   1110 0000   1000 0001   0000 0111   0011 1000   1110 0000   0000 0000   0000 0000

3    0      C    0      0    0      0    3      3    0      C    0      0    0      0    0
0011 0000   1100 0000   0000 0000   0000 0011   0011 0000   1100 0000   0000 0000   0000 0000

3    0      C    0      0    0      0    3      3    0      C    0      0    0      0    0
0011 0000   1100 0000   0000 0000   0000 0011   0011 0000   1100 0000   0000 0000   0000 0000

3    0      C    0      0    0      0    3      3    0      C    0      0    0      0    0
0011 0000   1100 0000   0000 0000   0000 0011   0011 0000   1100 0000   0000 0000   0000 0000

3    0      C    0      0    0      0    3      3    0      C    0      0    0      0    0
0011 0000   1100 0000   0000 0000   0000 0011   0011 0000   1100 0000   0000 0000   0000 0000

3    0      C    0      0    0      0    3      3    0      C    0      0    0      0    0
0011 0000   1100 0000   0000 0000   0000 0011   0011 0000   1100 0000   0000 0000   0000 0000

3    8      E    0      8    0      0    3      3    8      E    0      0    0      0    0
0011 1000   1110 0000   1000 0000   0000 0011   0011 1000   1110 0000   0000 0000   0000 0000

3    8      E    0      8    0      0    3      3    8      E    0      0    0      0    0
0011 1000   1110 0000   1000 0000   0000 0011   0011 1000   1110 0000   0000 0000   0000 0000

The only tricky part is that the bits in each byte are first reversed (or read right to left if you prefer). So the first two bytes for example get applied as:

0011 1111 0000 1111

As for the UI, when the mask byte is set (offset stored at 0x0E in the room data) it might make sense to create a separate canvas object that contains a black and white mask image to overlay the main room image (just an idea, maybe there's a better way).

Other rooms with masks are 22, 23, 40, 44, and 46, maybe others.

[gzip]

Note that the offset at 0x0E will point to a value of 0x00 or 0x01. If the value is 1 then the next byte will be the RLE run length (4 or 8 depending on the room size), followed by the RLE data.

[gmarty]

The data from the nask table is already parsed, but yeah the UI doesn't use it yet.

You can use the CLI to export the data that is parsed to JSON, so you can see what is done and what is missing:

node index.js --input path/to/rom --output resources.json

It's stored in the masktable entry. I compared the values for room 29 and they match that you posted.
As for the UI, we can simply use styled <div>, the way the object highlights are done.