Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement size boundaries based on current costume #202

Open
towerofnix opened this issue Jul 5, 2024 · 0 comments
Open

Implement size boundaries based on current costume #202

towerofnix opened this issue Jul 5, 2024 · 0 comments
Labels
compatibility Bugs that cause Leopard's behavior to differ from Scratch's

Comments

@towerofnix
Copy link
Member

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: #199 (comment)), 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%).
@towerofnix towerofnix added the compatibility Bugs that cause Leopard's behavior to differ from Scratch's label Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Bugs that cause Leopard's behavior to differ from Scratch's
Projects
None yet
Development

No branches or pull requests

1 participant