When MakeCode is compiled and there are things like strings which do not change, are these left in flash memory and referenced from there to reduce RAM usage? I’m thinking along the lines of Arduino/C’s PROGMEM but with the compiler figuring that out for itself.
[Added later]. Images in MakeCode Arcade are the more obvious data type for this treatment.
any image that is not created / edited programmatically (e.g. including img tagged templates) is stored in flash and brought over to memory only when it is editted (e.g. if you set pixels to the image at runtime), and we now have constant folding which inlines simple number operations / etc where possible (which is why infinity / nan were added in that pr, as it removed the memory allocation)
The other thing that’s kept in flash is hex literals. They can be used to store constant arrays (with a bit of encoding).
OTOH Const Foo = [1,2,3,…] generates rather inefficient code and takes RAM.
A common technique for reversing sprites images is to code it rather than have a second sprite image particularly given the lack of a feature to flip the image in sprite editor. What does the block flip picture horizontally (flipY method) do to the image? It sounds like it would be in RAM after that?
What would the technique described in Best practice making levels with the new tilemap editor do with the levels in the array, would they end up in RAM?
I’ve been using a big if statement for level switching which that OP describes as inelegant but maybe I’ve minimised the amount of RAM usage (by luck)?
All tile maps sit in flash as far as I know. You may have an array but it’s an array of pointers so it doesn’t take much ram.
That will create the image at runtime, so yes, flipX and flipY will take up space in memory