Leopard currently allows sprites to have any size. Apart from causing rendering bugs (mostly addressed by #199), this means sprites can grow unreasonably gigantic (potentially crashing the browser: https://github.com/leopard-js/leopard/pull/199#issuecomment-2210967921), and the "size" reporter/property certainly doesn't cap at the expected values.
We need to port the code that determines a sprite's effective size limits from Scratch, and assess compatibility:
Scratch bases the size limit based on the dimensions of the current costume. Switching costumes does not reassess if the sprite is now outside its new bounds - that only happens the next time a size-changing block is used.
We need to check what Scratch does when handling a costume with apparent zero dimensions.
We should also follow map the pipeline for handling a sprite's size completely, so we can see if there are any other internal hard limits.
Scratch always casts its size values to a non-NaN number. While we'll handle this in generated code with traits or strict number casting, user-written code shouldn't be able to set the size to a non-number (or NaN) value, either. Runtime should treat these values as zero.
It might be reasonable to address this separately from general size boundaries, because e.g. it's probably possible to set other properties to invalid values (with user code) too, and those at least in certain cases would cause fairly brutal errors. We could print warnings in the setter, etc, but the problem isn't unique to size (or related to size boundaries, apart from being treated as 0%).
Leopard currently allows sprites to have any size. Apart from causing rendering bugs (mostly addressed by #199), this means sprites can grow unreasonably gigantic (potentially crashing the browser: https://github.com/leopard-js/leopard/pull/199#issuecomment-2210967921), and the "size" reporter/property certainly doesn't cap at the expected values.
We need to port the code that determines a sprite's effective size limits from Scratch, and assess compatibility: