Discuss Scratch
![[RSS Feed]](http://cdn.scratch.mit.edu/scratchr2/static/__5b3e40ec58a840b41702360e9891321b__//djangobb_forum/img/feed-icon-small.png "[RSS Feed]"){kind=icon}
- dlongm01
-
Scratcher
15 posts
Stage Size
The visible Stage is 480 by 360 points but no sprite can be moved off the visible area completely. There is always an 18 point region that remains visible.
I understand from forum feedback that this is by design aimed at beginners; it is intended to prevent the apparent ‘loss’ of a sprite by accidentally positioning it at a point where it is no longer visible on the stage.
OK so far. I can understand that rationale as it applies to novices or the less experienced. In my own learning I can recall times when it was easy to be mystified by such things
However, a by-product of this is that this creates a' feature' such that when writing programs it forces one to adopt a non-logical workaround. There are quite a few conceivable cases where I would want to send a sprite right off the stage.
The particular case when I discovered this limitation is when I tried to make a simple sideways scrolling method using just two full-width sprites. The logical approach is to position one or other at X=+/- 480 while the left or right scrolling takes effect … but this cannot be done - there is always 18 pixels showing when I want to entire sprite to be invisible at that moment. To achieve this it becomes needlessly awkward - best i do is a special sprite to create a ‘proscenium’ border around the stage although this reduces the visible area of an already limited stage. So this is a converse case: the expectations of a slightly more experienced programmer (intermediate at best I hasten to add) are thwarted by the support-by-design for novices.
My suggestion is to make this switchable in some way. Perhaps by the use of an additional stage button that allows a non-restrictive use of the Stage. For example, in most versions of Logo there are three screen settings: Wrap, Fence and Window. Scratch by default is set to Fence. Why not create a Window/Fence setting with a toggle button or a new block?
As I still use version 1.4 it would be nice for this to be added to both V2.0 and V1.4. I can't imagine it would a difficult feature to implement
Thanks.
I understand from forum feedback that this is by design aimed at beginners; it is intended to prevent the apparent ‘loss’ of a sprite by accidentally positioning it at a point where it is no longer visible on the stage.
OK so far. I can understand that rationale as it applies to novices or the less experienced. In my own learning I can recall times when it was easy to be mystified by such things
However, a by-product of this is that this creates a' feature' such that when writing programs it forces one to adopt a non-logical workaround. There are quite a few conceivable cases where I would want to send a sprite right off the stage.
The particular case when I discovered this limitation is when I tried to make a simple sideways scrolling method using just two full-width sprites. The logical approach is to position one or other at X=+/- 480 while the left or right scrolling takes effect … but this cannot be done - there is always 18 pixels showing when I want to entire sprite to be invisible at that moment. To achieve this it becomes needlessly awkward - best i do is a special sprite to create a ‘proscenium’ border around the stage although this reduces the visible area of an already limited stage. So this is a converse case: the expectations of a slightly more experienced programmer (intermediate at best I hasten to add) are thwarted by the support-by-design for novices.
My suggestion is to make this switchable in some way. Perhaps by the use of an additional stage button that allows a non-restrictive use of the Stage. For example, in most versions of Logo there are three screen settings: Wrap, Fence and Window. Scratch by default is set to Fence. Why not create a Window/Fence setting with a toggle button or a new block?
As I still use version 1.4 it would be nice for this to be added to both V2.0 and V1.4. I can't imagine it would a difficult feature to implement
Thanks.
Last edited by dlongm01 (May 14, 2013 11:53:18)
- scimonster
-
Scratcher
1000+ posts
Stage Size
I rather agree with this.
The Team isn't updating 1.4 anymore though.
The Team isn't updating 1.4 anymore though.
- dusty22
-
Scratcher
100+ posts
Stage Size
+1.
I think the stage should be able to extend off-screen at least a smidget more than now.
I think the stage should be able to extend off-screen at least a smidget more than now.
- Rub0Gameton
-
Scratcher
100+ posts
Stage Size
+1. I completely support this. It really shouldn't be hard to implement, and it would really help out scrolling games and such. However, I find the title slightly misleading, as this isn't specifically talking about the stage size.
- Failord
-
Scratcher
1000+ posts
Stage Size
I rather agree with this.
The Team isn't updating 1.4 anymore though.
+1. I completely support this. It really shouldn't be hard to implement, and it would really help out scrolling games and such. However, I find the title slightly misleading, as this isn't specifically talking about the stage size.
Agree with everything said. Full support. I'm glad you posted this, because I was going to suggest the same thing myself.
One of the reasons is that in my game Asteroid Avoider, it was VERY hard to program the scrolling stars(that are sorta cruddy) and the asteroids and stuff dissapear before leaving the screen.
Please, put a switch button tucked away in the stage, ST! It wouldn't be confusing to new Scratchers if you added an information banner that shows up explaining about the switch(like with Cloud Data).
- jhcole
-
Scratcher
2 posts
Stage Size
I've been frustrated by this feature as well. I try to work around it by adding long edges to sprites such that these edges are always off screen. For example, imagine a sprite in the shape of a capital letter T. If you move this sprite as far left or right as possible, the vertical part will be completely off screen. If you move the sprite up enough that the horizontal part is off the top of the screen, the sprite is now completely off the screen. I've shared a demonstration using this effect to create side scrolling clouds.
workaround demonstration
workaround demonstration
- DadOfMrLog
-
Scratcher
1000+ posts
Stage Size
Nice workaround.
BTW, I think you can get away with something a bit neater than the big black rectangle… Try putting a completely transparent rectangle just around the cloud in your project - and make it about 50% bigger than just the cloud itself. This means the transparent part of the costume is the part that's just on the edge of the screen, and you don't have to worry about making it so far away from the main part of the costume.
Note that you can't make a completely transparent rect straight away in the editor (i.e. by choosing both outline and fill as transparent before you create the rect). Also, you can't make a rect with non-transparent outline have a transparent outline for some reason (the change doesn't seem to take effect in the costume, which is maybe a bug in the editor?) - you have to start with transparent outline before creating a filled rect. Once you have the fliled rect with transparent outline, you can fill it with transparent too.
Oh, and in case you want off-screen pen-drawing, take a look at the first project in this studio… http://scratch.mit.edu/studios/202972/
BTW, I think you can get away with something a bit neater than the big black rectangle… Try putting a completely transparent rectangle just around the cloud in your project - and make it about 50% bigger than just the cloud itself. This means the transparent part of the costume is the part that's just on the edge of the screen, and you don't have to worry about making it so far away from the main part of the costume.
Note that you can't make a completely transparent rect straight away in the editor (i.e. by choosing both outline and fill as transparent before you create the rect). Also, you can't make a rect with non-transparent outline have a transparent outline for some reason (the change doesn't seem to take effect in the costume, which is maybe a bug in the editor?) - you have to start with transparent outline before creating a filled rect. Once you have the fliled rect with transparent outline, you can fill it with transparent too.
Oh, and in case you want off-screen pen-drawing, take a look at the first project in this studio… http://scratch.mit.edu/studios/202972/
- j3nnif3r
-
Scratcher
1 post
Stage Size
I agree! My children and I have been working with Scratch together and the amount of non-intuitive workarounds that we have had to do to create a game that scrolls horizontally is so frustrating to them.
- frodewin
-
Scratcher
500+ posts
Stage Size
+1
There has been a similar request already by Griffpatch, I guess there had been others as well. Is there any chance to get this implemented in a future version of Scratch?
There has been a similar request already by Griffpatch, I guess there had been others as well. Is there any chance to get this implemented in a future version of Scratch?
- TimothyLawyer
-
Scratcher
1000+ posts
Stage Size
Maybe require all sprites (visible or not) to be in a position where they are within the 18 pixel inset border of the stage when the green flag is clicked.
If a sprite has been moved off stage, it is automatically moved back by clicking the green flag. So sprites do not get lost off the stage.
However, Scratchers who want to move a sprite off stage can do so while the project is running. They can do it using the ‘go to’, set x, y and ‘glide’ blocks.
Regular Scratch click and drag of a sprite won't allow a sprite to be moved (completely) off stage. However, combining the above blocks with the various click-and-drag workarounds would allow a Scratcher to program a game where the viewer of a project is able to drag a sprite to an off-stage position.
In any event, clicking the green flag would reset all sprites back to on stage. So sprites would never get lost.
And Scratchers would have to work around this beginner-friendly feature if they want to make use of a sprite-off-stage capability (such as tracking off-stage sprites last positions in a list and then moving the sprites back to an off-stage position after the green flag is clicked).
If a sprite has been moved off stage, it is automatically moved back by clicking the green flag. So sprites do not get lost off the stage.
However, Scratchers who want to move a sprite off stage can do so while the project is running. They can do it using the ‘go to’, set x, y and ‘glide’ blocks.
Regular Scratch click and drag of a sprite won't allow a sprite to be moved (completely) off stage. However, combining the above blocks with the various click-and-drag workarounds would allow a Scratcher to program a game where the viewer of a project is able to drag a sprite to an off-stage position.
In any event, clicking the green flag would reset all sprites back to on stage. So sprites would never get lost.
And Scratchers would have to work around this beginner-friendly feature if they want to make use of a sprite-off-stage capability (such as tracking off-stage sprites last positions in a list and then moving the sprites back to an off-stage position after the green flag is clicked).
- frodewin
-
Scratcher
500+ posts
Stage Size
However, Scratchers who want to move a sprite off stage can do so while the project is running. They can do it using the ‘go to’, set x, y and ‘glide’ blocks.
Unfortunately this does not work. Even while a project is running, it does not allow the sprite to move off the stage completely with ‘go to’, set x, y and ‘glide’ blocks.
You can try this out with a new project and then adding this script to the scratch cat (it works the same without the forever loop, added it just to claim that the project is still running):
when green flag clicked
forever
glide (1) secs to x: (286) y: (0)
end
The glide will stop at x=271, still showing a part of the scratch cat.
Last edited by frodewin (Sept. 16, 2014 22:42:36)
- TimothyLawyer
-
Scratcher
1000+ posts
Stage Size
Unfortunately this does not work. Even while a project is running, it does not allow the sprite to move off the stage completely with ‘go to’, set x, y and ‘glide’ blocks.That is correct. My comment was meant as a proposal or suggestion for how off-screen sprites could be handled in Scratch while keeping things okay for beginning programmers.
You can try this out with a new project and then adding this script to the scratch cat (it works the same without the forever loop, added it just to claim that the project is still running):when green flag clicked
forever
glide (1) secs to x: (286) y: (0)
end
The glide will stop at x=271, still showing a part of the scratch cat.
Last edited by TimothyLawyer (Sept. 17, 2014 03:05:41)
- CGRises
-
Scratcher
500+ posts
Stage Size
No support. This is rather easy to workaround, like this:
foreverAnd you replace the “Furthest…” Blocks with the corresponding values.
if <<<<(X position) = (Furthest possible location to the left)> or <<(X position) = (Furthest possible location to the Right)> >> or < <(Y position) = (Furthest possible Upward location )>>> or < <(Y position) = (Furthest possible Downward location )>>> then
Hide
Else
show
end
end
- Snips500
-
Scratcher
8 posts
Stage Size
Dear scratch team can you make the screen size (or stage) a square it has mest up a few of my projects XD
Please consider
Please consider
- DerekEducation
-
New Scratcher
1 post
Stage Size
put a 19-pixel border around the edge of the stage. Sprites can disappear behind it as they approach the edge of the stage
- Hunterlore
-
Scratcher
2 posts
Stage Size
The visible Stage is 480 by 360 points but no sprite can be moved off the visible area completely. There is always an 18 point region that remains visible.
I understand from forum feedback that this is by design aimed at beginners; it is intended to prevent the apparent ‘loss’ of a sprite by accidentally positioning it at a point where it is no longer visible on the stage.
OK so far. I can understand that rationale as it applies to novices or the less experienced. In my own learning I can recall times when it was easy to be mystified by such things
However, a by-product of this is that this creates a' feature' such that when writing programs it forces one to adopt a non-logical workaround. There are quite a few conceivable cases where I would want to send a sprite right off the stage.
The particular case when I discovered this limitation is when I tried to make a simple sideways scrolling method using just two full-width sprites. The logical approach is to position one or other at X=+/- 480 while the left or right scrolling takes effect … but this cannot be done - there is always 18 pixels showing when I want to entire sprite to be invisible at that moment. To achieve this it becomes needlessly awkward - best i do is a special sprite to create a ‘proscenium’ border around the stage although this reduces the visible area of an already limited stage. So this is a converse case: the expectations of a slightly more experienced programmer (intermediate at best I hasten to add) are thwarted by the support-by-design for novices.
My suggestion is to make this switchable in some way. Perhaps by the use of an additional stage button that allows a non-restrictive use of the Stage. For example, in most versions of Logo there are three screen settings: Wrap, Fence and Window. Scratch by default is set to Fence. Why not create a Window/Fence setting with a toggle button or a new block?
As I still use version 1.4 it would be nice for this to be added to both V2.0 and V1.4. I can't imagine it would a difficult feature to implement
Thanks.