We should try to convert item PLMs to proper sprites (i.e., drawn on the sprite layer.) This would give us a lot more flexibility in terms of palettes and it's something we can contribute back to the general SM hacking community. I don't fully understand how sprite allocation and handling works in Super Metroid but at a high level I think it would involve the following:
-
Making sprite maps/pointers for every item and writing some boilerplate "AI" logic that switches the palettes to mimic how items flash currently but otherwise just scrolls them with the screen. We should load item gfx as 16x16 tiles into the region in VRAM around $7C00 and use one 16x16 OAM allocation per rather than load them in an alternating upper 1, lower 1, upper 2, lower 2 pattern as vanilla does. This has room for 4 sprites (account for flash animation) that aren't already present in VRAM.
-
Making new, unique palettes for existing items that contains the colors for both frames then converting vanilla gfx to use these palettes. Every room should have at least one free sprite palette per item. I think the vanilla conversion could be done with a small CLI tool that runs during the base rom build process.
-
Rewriting item PLM drawing logic to handle OAM allocation, palette allocation, etc instead of drawing on the BG layer.
In theory we should be able to do this as a drop-in implementation that looks exactly the same as vanilla pending any issues with things like palette availability per room in CGRAM. I'd expect it to be a little more expensive than the current BG version but that will be offset by not running the vanilla logic and the fact that the sprites don't need to do anything but switch palettes (the vanilla method already keeps both copies of item gfx in VRAM and simply swaps tiles.) We may also save a little time by storing all our gfx as 16x16 sprites instead of four 8x8 tiles.
We should try to convert item PLMs to proper sprites (i.e., drawn on the sprite layer.) This would give us a lot more flexibility in terms of palettes and it's something we can contribute back to the general SM hacking community. I don't fully understand how sprite allocation and handling works in Super Metroid but at a high level I think it would involve the following:
Making sprite maps/pointers for every item and writing some boilerplate "AI" logic that switches the palettes to mimic how items flash currently but otherwise just scrolls them with the screen. We should load item gfx as 16x16 tiles into the region in VRAM around $7C00 and use one 16x16 OAM allocation per rather than load them in an alternating upper 1, lower 1, upper 2, lower 2 pattern as vanilla does. This has room for 4 sprites (account for flash animation) that aren't already present in VRAM.
Making new, unique palettes for existing items that contains the colors for both frames then converting vanilla gfx to use these palettes. Every room should have at least one free sprite palette per item. I think the vanilla conversion could be done with a small CLI tool that runs during the base rom build process.
Rewriting item PLM drawing logic to handle OAM allocation, palette allocation, etc instead of drawing on the BG layer.
In theory we should be able to do this as a drop-in implementation that looks exactly the same as vanilla pending any issues with things like palette availability per room in CGRAM. I'd expect it to be a little more expensive than the current BG version but that will be offset by not running the vanilla logic and the fact that the sprites don't need to do anything but switch palettes (the vanilla method already keeps both copies of item gfx in VRAM and simply swaps tiles.) We may also save a little time by storing all our gfx as 16x16 sprites instead of four 8x8 tiles.