bounce::motion

and

<on edge?::motion>

Someone could easily recreate the old block using

if <on edge?::motion> then
    bounce::motion
end

Which way would it bounce if it wasn't touching the edge.

9kiwi9 wrote:

(On edge? :: motion)

This can already be done like this:

<touching [edge v]?>

Like tram pointed out, touching edge already exists. It's a basic block.

But I DO support the bounce part. It's something that would make collision easy for new scratchers.

if <touching [wall1 v]?> then
    bounce::motion
end

What would “bounce” do?

EDIT: Also, what would the following do?

when gf clicked
go to x:(0) y:(0)
forever
bounce :: motion
end

I think there should be an

if touching [edge v], bounce :: motion

block instead. You can't bounce off of nothing!

Support.

spgame05 wrote:

I think there should be an

if touching [edge v], bounce :: motion

There could also be a

if touching color [#f0f] bounce // category=motion

I wish there could just be a bounce block, but as spgame05 put it,

spgame05 wrote:

You can't bounce off of nothing!

Greatguy123 wrote:

Support.

spgame05 wrote:

I think there should be an

if touching [edge v], bounce :: motion

There could also be a

if touching color [#f0f] bounce // category=motion

I wish there could just be a bounce block, but as spgame05 put it,

spgame05 wrote:

You can't bounce off of nothing!

Yes. And

AonymousProfessor wrote:

What would “bounce” do?

EDIT: Also, what would the following do?

when gf clicked
go to x:(0) y:(0)
forever
bounce :: motion
end

would probably do nothing.

Support

forever
    
think [Remember: Think this and think that and think low and think high, oh the things you can think if you only try!]
end

spgame05 wrote:

I think there should be an

if touching [edge v], bounce :: motion

block instead. You can't bounce off of nothing!

Yeah, so do I.

turn blank () degrees
bounce

same same

derpmeup wrote:

spgame05 wrote:

I think there should be an

if touching [edge v], bounce :: motion

block instead. You can't bounce off of nothing!

Yeah, so do I.

How would an object bounce on a really crooked set of bitmap spikes?

[ v]

Just “bounce” wouldn't work well.
Instead, this would…

if <>, bounce ::motion

1234abcdcba4321 wrote:

Just “bounce” wouldn't work well.
Instead, this would…

if <>, bounce ::motion

How would that work? What would

if <[1] = [1]>, bounce ::motion

do? I think we should have my idea of

if touching [edge v], bounce :: motion

and Greatguy123's idea of

if touching color [#f0f], bounce :: motion

instead.

spgame05 wrote:

if touching color [#f0f], bounce :: motion

There is an easy workaround for this.

when green flag clicked
forever
    
if <touching color [#f0f]?> then
if <(x position) > [0]> then
change x by (-50)
else
if <(x position) < [0]> then
    
change x by (50)
end
    
end
    
end
end

derpmeup wrote:

spgame05 wrote:

if touching color [#f0f], bounce :: motion

There is an easy workaround for this.

when green flag clicked
forever
    
if <touching color [#f0f]?> then
if <(x position) > [0]> then
change x by (-50)
else
if <(x position) < [0]> then
    
change x by (50)
end
    
end
    
end
end

I think “bounce” is more pointed towards rotation.

spgame05 wrote:

1234abcdcba4321 wrote:

if touching color [#f0f], bounce :: motion

when green flag clicked
forever
    
if <touching color [#f0f]?> then
    
turn right (180) degrees
end
end

spgame05 wrote:

1234abcdcba4321 wrote:

Just “bounce” wouldn't work well.
Instead, this would…

if <>, bounce ::motion

How would that work? What would

if <[1] = [1]>, bounce ::motion

do? I think we should have my idea of

if touching [edge v], bounce :: motion

and Greatguy123's idea of

if touching color [#f0f], bounce :: motion

instead.

I still like mine.
The block needs a boolean statement, which is why just a regular bounce wouldn't work.

VoltageGames wrote:

Like tram pointed out, touching edge already exists. It's a basic block.

But I DO support the bounce part. It's something that would make collision easy for new scratchers.

if <touching [wall1 v]?> then
    bounce::motion
end

I would like a bounce block that would bounce off objects depending on the angle it approaches (I don't quite understand why direction isn't measured 0-360 degrees). I am just a novice and I have tried making my own Breakout game. The best code I found to deal with it are in this project.

However I do take on the fact that:

A-no-meep wrote:

How would an object bounce on a really crooked set of bitmap spikes?

There's no way you could bounce off a general shape without calculus. And, as A-no-meep said, there would be an issue with diagonal bitmap surfaces.

Let 0 be the surface, 1 be the impactor, and represent all other pixels. It will look like this before impact:

0
00 1
000 111
0000 1
00000
000000
0000000
00000000
000000000

If the impactor continues to move, say, southwest, it will look like this:

0
00
000
0000 1
00000111
0000001
0000000
00000000
000000000

But what will it do? It can't determine an orientation. If it had to randomly choose from up or right, it would look wonky regardless of the outcome:

0 1
00 111
000 1
0000
00000
000000
0000000
00000000
000000000

This violates the laws of reflection! If it was a bigger diamond-shape or octagon, it would get stuck. If it touched the surface by the corners, it wouldn't be able to find an orientation. If it decides to reflect back, it will again violate the laws of reflection for any surface that is not “perpendicular” to the impactor's “direction”.

The only way to determine the “angle” of the bitmap surface is to analyze the surrounding pixels and estimate the reflection angle, which, again, requires the use of calculus.

However, this is not an issue with vectors, as you can design a program with an extra sprite that measures the orientation and tells the shape which way to go.

bounce :: motion

Whaaaa? Bounce of what angle? What edge? And what if it is touching two things?

ShamelessSnores wrote:

3sal2 wrote:

There's no way you could bounce off a general shape without calculus. And, as A-no-meep said, there would be an issue with diagonal bitmap surfaces.

Let 0 be the surface, 1 be the impactor, and represent all other pixels. It will look like this before impact:

0
00 1
000 111
0000 1
00000
000000
0000000
00000000
000000000

If the impactor continues to move, say, southwest, it will look like this:

0
00
000
0000 1
00000111
0000001
0000000
00000000
000000000

But what will it do? It can't determine an orientation. If it had to randomly choose from up or right, it would look wonky regardless of the outcome:

0 1
00 111
000 1
0000
00000
000000
0000000
00000000
000000000

This violates the laws of reflection! If it was a bigger diamond-shape or octagon, it would get stuck. If it touched the surface by the corners, it wouldn't be able to find an orientation. If it decides to reflect back, it will again violate the laws of reflection for any surface that is not “perpendicular” to the impactor's “direction”.

The only way to determine the “angle” of the bitmap surface is to analyze the surrounding pixels and estimate the reflection angle, which, again, requires the use of calculus.

However, this is not an issue with vectors, as you can design a program with an extra sprite that measures the orientation and tells the shape which way to go.

Diamond_Projects wrote:

(bounce :: motion)

Whaaaa? Bounce of what angle? What edge? And what if it is touching two things?

Please do not necropost.

I'm telling you why the “bounce” block won't work! How is that a necropost?