Open ace-dent opened 1 year ago
Earlier, I said that it was a kludge to keep viper happy, but I now realize there is a behavior-based motivation for this: we may want sprites to be mutable, so that people can do per-sprite texture changes at runtime. If RAM usage concerns become critical due to this design, we can discuss a new streamedSprite
or immutableSprite
object to accommodate the use case, but myself and the other engineers at TC believe this to be significantly distinct from current Sprite
behavior, and we think that it probably needs a different name.
More or less directly continuing the Discord conversation --
If one has a singular tileset/spritesheet that never changes, ROM reads are a better fit, but immutability can get in the way when people want to do anything more complex than typical masking operations on, say, a bunch of fairly small sprites.
A driving principle of the API is one of minimizing user astonishment. If we added this functionality in the same elif
train as the rest of the sprite initialization, the mutability of the sprite would be a non-intuitive function of the __init__
parameters, which would surprise me from a design standpoint, even if it was documented. This could be solved by flipping a coin to simply choose either mutable or immutable sprites, but we've painted ourselves into a corner by already assuming mutability of the Sprite
in legacy. To me, it seems most preferable to implement both, and keep their differences rather explicit.
Note from @fuglaro on Discord, to test any RAM saving for Sprites created from a binary .bin
file (loaded as bytes
vs bytearray
):
Yeah, and I think the memory saving scenarios are pretty nuanced. I think that one needs verification. I actually think that situation won't save any memory... Reason being: Literally coded bytes already exist in the python bytecode created by interpreting the python files, and since they aren't mutable, they don't need to be duplicated into new memory, so can be referenced from the python bytecode directly. That's not the case in the scenerio you point out
Following a discussion on Discord: It seems using
bytes()
(immutable) rather thanbytearray()
may save RAM, as the data is accessed directly from flash (details). It would make sense if bitmap data used this.blit()
methods supports this; code should be verified.file.bin
; are we loading into anotherbytearray
/ can we save any RAM here?bytes
.Before starting this work, we must confirm RAM is saved at execution time. CC @fuglaro.