-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Try adding "stretch x" and "stretch y" options to the "size" blocks #982
Comments
I’d like this! |
What if each corner (of the rectangular field the image occupies) could be independently modeled? This would probably fit better as an extension, but would allow you to do some really color stuff. |
Could it be confusing if I inadvertently set stretch y and I'm trying to use stretch x to fix it? |
I've wondered in the past if an alternative to "stretch" might be some kind of "aspect ratio" block? – That would avoid confusion that could come about when stretching in both X & Y, as well as its 'operational overlap' with the "size" block. It would also avoid potential confusion over use of "X" and "Y" (i.e. in "stretch X" and "stretch Y") when a sprite is rotated such that its (original) X axis is no longer coincident with the X axis on screen (I'm assuming that stretching operations would be applied to the costume before rotation...) |
Or you could have set size always set the X & y size, and have a set width
and set height that work independently, but are both set by set size :)
just throwing that out there!
…On Tue, 3 Apr 2018, 21:16 Aka DadOfMrLog, ***@***.***> wrote:
I've wondered in the past if an alternative to "stretch" might be some
kind of "aspect ratio" block? – That would avoid confusion that could come
about when stretching in both X & Y, as well as its 'operational overlap'
with the "size" block.
It would also avoid potential confusion over saying "X" and "Y" when a
sprite is rotated such that its (original) X axis is no longer coincident
with the X axis on screen (I'm assuming that stretching operations would be
applied to the costume before rotation...)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#982 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGbNvkeR4xxqWRSSsvePG59o3xWOxmmrks5tk9iCgaJpZM4St-q5>
.
|
(Sorry... this ended up getting longer than expected... just for a change...) I think the downside to having width+height+size would be that it makes the size behave in a way that's a bit less intuitive after having changed the width. If someone wants to change the overall size of a costume that already has width set to something other than 100%, then it means either scaling up both width & height by the desired amount, or else changing first the size and then changing the width again (to a different value to account for the new size). My feeling is that what's really expected would be that the size scales the costume 'as-is' (i.e. after it has already been stretched). Hence leading naturally to the concept of having a way to change the aspect-ratio, with the size then just scaling the costume whilst keeping that aspect-ratio fixed. It might be worth considering just having a single "set stretch to ( )%" block (or something vaguely like "set aspect-ratio to 1:( )"?) which only changes the horizontal width of the costume (before rotation). That's enough to get any desired effect when used along with "set size". It'll clearly lead to the question "why is there no vertical stretch...?" – but then I'm not against the idea of reducing the number of available operations/blocks where it can provide an opportunity to learn something worth knowing (even though it could even be very simple, such as that the much-suggested "previous costume" block can be easily emulated by "switch costume to (costume#-1)"). In this case, to discover (either through someone else's explanation or by one's own experimentation) that stretching vertically by, say, a factor of two is equivalent to setting the horizontal stretch/width (/aspect) to 50% (/0.5) along with scale of 200%. On a side note, I do wonder about using the word "stretch", when it's expressed as a percentage with 100% corresponding to no stretching. It feels to my brain as though that actually means double the width, and that zero should mean "no stretching" (so shrinking would be negative). That's why I'd prefer using "width" (and "height"), if it's going to be expressed as a percentage and amalgamated with the "size" block in the way originally suggested. Or else something like "aspect-ratio". |
@Mr-Dave2: I wonder if it was potentially a bit confusing to use alongside "set size"...? |
@TheLogFather It's likely that the Scratch team has had this conversation in the past and that these options were tested in their clubhouse sessions. A later version of Scratch has the stretch block and then it was removed (but still exists as an obsolete block.) It might be helpful if anyone who saw these being used could comment on how well they were understood. |
In an effort to lobby support for having this feature, in some form, added to Scratch I've written program with a simulated stretch function. Scratch 2.0 and Scratch 3.0 |
Awesome 👍 Lets do that stretch thing :) |
And nothing has come of this?.. It would be a tremendous help if the Scratch Team could add sprite deforming in any of those forms. The possibilities! I think the creative potential of a high quality deform block would well outweigh the problem solving skills gained by trying to write your own that probably runs so slow, or is such low quality, or simply too big, to use anyways. |
We should just replace the Set Size block to be an overwrite for both Size X and Size Y, for example "Set Size X and Y to %100". And there should just be "Set size X to %50" and "Set size Y to %100" instead of using stretch blocks that are relative to an already existing size value. It would be the most straightforward and functionally correct way to have stretching natively. |
Following up on the great work in #249 on designing and prototyping an effect that scales a sprite on each axis, @carljbowman and I have a new proposal:
It could fit nicely as menu options in the "set size" and "change size" blocks.
This is a better fit than applying it as a graphic effect. Stretching is closely related to size, and it naturally defaults to 100 (for no change), much like size (while graphic effects default to 0 for no effect).
So the proposed blocks would be:
[ Change [size / stretch x / stretch y] by [10] ]
[ Set [size / stretch x / stretch y] to [100] % ]
The text was updated successfully, but these errors were encountered: