These four screenshots compare the opening setting of the game in Sameboy and PyBoy. In Sameboy we see Samus clearly against the black background, and when Samus is inside the ship she can only be viewed through the window (I curled into a ball so you can see clearly). In PyBoy, Samus is not visible at all against the black background, and inside the ship, we only see her sprite where she overlaps with the white ship exterior.
The reason for this is that we store the flags for BG Priority and Color 0 in the 32-bit color palette LUT, but don't update it when that palette is changed. To start with, white is color 0, and the table is updated likewise, and white continues to be the transparent color even though the game updated the palette to make color 0 black (11) instead of white (00).
I'm not sure if this is the best fix, but it works for Metroid and seems to make more sense than what we had before. There's a question of efficiency, sure, but I don't think we can cache it in set(...) unless we shuffle the order of self.lookup every time--it's possible for two colors to point to the same shade in self.lookup but only one might be color 0.
Then again, maybe a better version of this would simply do away with the double table lookup in getcolor(..) and have set(..) update its RGB lookup table from an internal shade table instead. That would likely be faster and I think this method has been identified as a cause of slowdown before. Feel free to reject and do that instead if you prefer.
[copied from discord]
These four screenshots compare the opening setting of the game in Sameboy and PyBoy. In Sameboy we see Samus clearly against the black background, and when Samus is inside the ship she can only be viewed through the window (I curled into a ball so you can see clearly). In PyBoy, Samus is not visible at all against the black background, and inside the ship, we only see her sprite where she overlaps with the white ship exterior.
The reason for this is that we store the flags for BG Priority and Color 0 in the 32-bit color palette LUT, but don't update it when that palette is changed. To start with, white is color 0, and the table is updated likewise, and white continues to be the transparent color even though the game updated the palette to make color 0 black (11) instead of white (00).
I'm not sure if this is the best fix, but it works for Metroid and seems to make more sense than what we had before. There's a question of efficiency, sure, but I don't think we can cache it in set(...) unless we shuffle the order of self.lookup every time--it's possible for two colors to point to the same shade in self.lookup but only one might be color 0.
Then again, maybe a better version of this would simply do away with the double table lookup in
getcolor(..)and haveset(..)update its RGB lookup table from an internal shade table instead. That would likely be faster and I think this method has been identified as a cause of slowdown before. Feel free to reject and do that instead if you prefer.