Sprite Graphic Set bytes findings
There are six bytes that define the sprites's graphics sets for a room. Putting findings here as learn more about them.
These dumps were ran by doing 0->f one at a time for each byte, for a total of 16*6 combinations.
Ludwig was determined manually
| sprite | id | valid at |
|---|---|---|
| Boo | 2f |
6 -1 -1 -1 -1 [0-f] and 8 -1 -1 -1 -1 [0-f]
|
| Thwomp | 8a | 6 -1 -1 -1 -1 [0-f] |
| Thwimp | d0 | -1 -1 -1 -1 -1 d |
| Ludwig | 1,14 | -1 -1 2 -1 -1 5 |
| Goomba | 72 |
-1 -1 -1 2 -1 -1 through -1 -1 -1 f -1 1
|
| Green Koopa | 6c |
-1 -1 -1 2 -1 -1 through -1 -1 -1 f -1 -1
|
| Mushroom | d | valid in all sets |
| BoomBoom | 4b | [1-f] [1-f] [1-f] [1-f] [1-f] 0 |
-1 means that entity does not care about that slot, it can be anything. slots must be positive once actually set in a level though
[0-f] means that slot can almost be anything, but it can't go above f`. See notes about bowser below
- simpler sprites only need one byte, but more complex need more (Ludwig)
- the need for more is just because they have more animations and thus load more tiles
- zero is a valid value. BoomBoom requires slot six be zero
- sprites can show up in more than one set (see Boo, Goomba, Koopa)
- so far all explorations of values above f yield empty results
- except mushroom, which appeared in all sets from 0x10->0x20
- possibly super common sprites have no graphic set at all, but their tiles/palette are always present no matter what
- except bowsers, see below
- so far it seems like object set, background, etc are totally irrelevant. Want water enemies underground? no problem
- Goomba and Koopa were valid for all byte values in the fourth slot except
1. Possibly one's are special or invalid?
Since boo is valid at 6 -1 -1 -1 -1 -1 and 8 -1 -1 -1 -1 -1, is it reasonable to guess the other bytes make no difference?
I did a run where the graphic set's default values are 2 3 4 5 6 7 and still found boo valid at 6 3 4 5 6 7 and 8 3 4 5 6 7. Seems to suggest the other bytes are irrelevant and a sprite only cares about the byte value for the bytes it is interested in.
Both SMB3 bowser and classic bowser require slot six to be 0x16. So far this is very unusual. Some sprites do not like it when slot six is 0x16 and thus cannot be in the same room as bowser. even more curious, these sprites generally don't care if that slot is anything from 0 to f.
this has been solved. the 26th byte of level settings needs to be zero for these to appear correctly
TCRF notes the arrow lift from yoshi's island is in the game: https://tcrf.net/Super_Mario_Advance_4:_Super_Mario_Bros._3/Unused_Objects#Arrow_Lift
I agree it is in the game. When you load a sprite with id e8 you do get an entity that acts just like the lift. But it's using bogus graphics, the tiles are from the seesaw platform. I did a full brute force dump of all graphic sets from 0 -> ff across all slots and still did not get the correct graphics. There is still something about sprites and graphic sets I do not understand.
So far the same is proving true for the floating block, I have yet to get this to show up correctly either.
One theory I had is they are 5 or 6 byte sprites, and use one of the bytes to further set their tiles, just like Ludwig. But all my investigation strongly suggests they are simple 4 byte sprites.
Donut blocks are a great example. When they fall away, they become sprites. And if their graphic set is not specified, they will show garbled graphics during this.
The one way doors in mushroom04,room1 (Doors a plenty) never show up correctly no matter how you set the first six bytes. But setting the 5th byte after the six to zero causes it to show up correctly. So in the entire level settings byte stream, byte at index 26d needs to be zero for the one way doors to show up.
This proved true for arrow lift and floating block as well
Flutter is definitely at id 01 17 as TCRF states. But so far have not been able to get its tiles loaded correctly. Pretty sure those unknown bytes in level settings will be the key to this.