How do I make a sprite appear disappear as they move on and off screen?

DKrisGlover

I have a situation where my main sprite moves through a bunch of other opposing sprites… I can't figure out a smooth way to make them appear and disappear at the edge of the screen as I approach and disappear as I move away. Seems like I have a ton of inefficient blocks to get it to work, then it breaks sometimes and I can't figure out why.

LobsterCrazy

Have you tried checking whether the sprite is touching an edge? Something like:

footsocktoe

DKrisGlover wrote:
I have a situation where my main sprite moves through a bunch of other opposing sprites… I can't figure out a smooth way to make them appear and disappear at the edge of the screen as I approach and disappear as I move away. Seems like I have a ton of inefficient blocks to get it to work, then it breaks sometimes and I can't figure out why.

Use these blocks… HIDE … SHOW

DKrisGlover

footsocktoe wrote:
DKrisGlover wrote:
I have a situation where my main sprite moves through a bunch of other opposing sprites… I can't figure out a smooth way to make them appear and disappear at the edge of the screen as I approach and disappear as I move away. Seems like I have a ton of inefficient blocks to get it to work, then it breaks sometimes and I can't figure out why.
Use these blocks… HIDE … SHOW[/quote
footsocktoe wrote:
DKrisGlover wrote:
I have a situation where my main sprite moves through a bunch of other opposing sprites… I can't figure out a smooth way to make them appear and disappear at the edge of the screen as I approach and disappear as I move away. Seems like I have a ton of inefficient blocks to get it to work, then it breaks sometimes and I can't figure out why.
Use these blocks… HIDE … SHOW

I'm using them but I'm not triggering them properly.

DKrisGlover

LobsterCrazy wrote:
Have you tried checking whether the sprite is touching an edge? Something like:

I just tried this and no joy… also tried using the distance to sprite, since my main sprite stays in the center, and it didn't help. I have something out of order, there something I'm not understanding about how Scratch goes down the chain and sees the commands.

The only thing that seemed to work is having my background sprite, broadcast a message of when to show up.

My setup is, my background cycles through 110 costumes to give the illusion of movement. At a certain point, it broadcasts a message and upon receiving, that message, each sprite activates SHOW and sets position and starts moving with the background. But they bunch up at the edge of the screen after I'm past them instead of disappearing.

footsocktoe

DKrisGlover wrote:
LobsterCrazy wrote:
Have you tried checking whether the sprite is touching an edge? Something like:
I just tried this and no joy… also tried using the distance to sprite, since my main sprite stays in the center, and it didn't help. I have something out of order, there something I'm not understanding about how Scratch goes down the chain and sees the commands.

The only thing that seemed to work is having my background sprite, broadcast a message of when to show up.

My setup is, my background cycles through 110 costumes to give the illusion of movement. At a certain point, it broadcasts a message and upon receiving, that message, each sprite activates SHOW and sets position and starts moving with the background. But they bunch up at the edge of the screen after I'm past them instead of disappearing.

Maybe you are unaware that a sprite cannot move completely off screen. It doesn't matter how big you make x. So hide the sprite when it reaches the edge.

serprinss

try this script

AlveKatt

Anywhere, in just one place though.

In the background Sprite.

Using a 2d-version of the same kind of code in many of my projects, including this one:
https://scratch.mit.edu/projects/100797558/#player
Note the frame that is there to hide that sprites can't go completely off screen.

Last edited by AlveKatt (Aug. 1, 2016 12:44:29)

TheLogFather

Do you mean that the sprite gets ‘stuck’ at the edges, ad you can't make it ‘slide’ off smoothly before it disappears?

If so, this is a particular foible of Scratch – it tries to ‘help’ you avoid ‘losing’ your sprite by making sure that it can't go off the screen. It's particularly annoying when you actually *want* that to happen…

One of the ways to sort of do it, as mentioned just above by @AlveKatt, is to put a frame around the edge of the screen which covers the sprite(s) at the point they get stuck. It probably needs to be ~20 pixels wide (nearly) to be sure to cover it completely.

However, there are several ways to ‘trick’ Scratch into doing it properly:
1) Switch to a larger costume, move to where you want it, then switch back to the normal costume.
2) Resize the costume to, say, twice the size, move to where you want it, resize back to normal size.
3) Add a very small, almost invisible, item (if in vector) or pixel (if bitmap) to the sides of the costume. (I use this method in this project, for example.)

(1) and (2) both work because Scratch only limits the position when you actually move the sprite. If the sprite is large enough to still be onscreen when you move it, then Scratch will let it move to where you told it. Then you change the costume/size back to what you want, and Scratch keeps it where you moved it to, even though it is now offscreen because the costume is smaller. The downside with both of these two methods is that switching costume or resizing is quite an intensive operation, so if you do it too frequently, for too many things (maybe you have lots of clones) then it will slow down everything.

(3) works because the costume hasn't really quite gone offscreen – your extra bit of costume is still onscreen, but the main part that really matters has gone offscreen. It'll look fine if the extra bit of costume is really hard to see against the background, but if there are high constrast regions in the background (say, some is black, some is white) then it may be hard to make a pixel/item that cannot be seen against one such region.

Hope that helps!

Last edited by TheLogFather (Aug. 1, 2016 15:06:38)

DKrisGlover

Thanks guys. these are good suggestions… for the moment, I think I kinda got it figured but I think it's inefficient. I'm going to try using that “forever” block more often… Seems like I'm not getting the benefit of it.

cj0603

Look at my project called A friendly conversation. I did a thing there that might help you out if it doesn't work give me a holler on my profile page

gtoal

DKrisGlover wrote:
Thanks guys. these are good suggestions… for the moment, I think I kinda got it figured but I think it's inefficient. I'm going to try using that “forever” block more often… Seems like I'm not getting the benefit of it.

Actually that's a habit that it would be best not to start. Have ONE forever loop in your main controller sprite, and get it to broadcast ‘next frame’ messages to all other sprites. When those sprites receive that message, they execute the code for one frame of animation - NOT in a loop. If you structure your code this way you should have fewer unexpected lag problems.

G

Mr-Animator

gtoal wrote:
DKrisGlover wrote:
Thanks guys. these are good suggestions… for the moment, I think I kinda got it figured but I think it's inefficient. I'm going to try using that “forever” block more often… Seems like I'm not getting the benefit of it.

Actually that's a habit that it would be best not to start. Have ONE forever loop in your main controller sprite, and get it to broadcast ‘next frame’ messages to all other sprites. When those sprites receive that message, they execute the code for one frame of animation - NOT in a loop. If you structure your code this way you should have fewer unexpected lag problems.

G

Sounds like a good strategy: however, is there not any overhead/lag issues created when you use lots of broadcasts? Not really sure what's going on with them behind the scenes…

TheLogFather

Mr-Animator wrote:
Sounds like a good strategy: however, is there not any overhead/lag issues created when you use lots of broadcasts?

Yes, there is actually. Because of the way that Scratch searches for receiver scripts, it could potentially be more CPU-intensive to send lots of continuous broadcasts rather than running lots of forever loops.

However, I'd never actually say that out loud (oh… err… oops…) since doing such things with broadcasts will help keep your scripting much more under control, and make it way easier to add things like a pause feature (only needs to be in one place, rather than every loop).
But, in particular, the difference it makes is really quite minimal – it takes a lot of broadcasts, all firing every frame, along with a lot of receiver scripts, for it to become an issue.

Discuss Scratch