Sheep_maker wrote:

stickfiregames wrote:

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

Don't suggest this! It is already suggested.
And the color should be reported in decimal (0-16777215) which is compatible with the Scratch color inputs.

Btw I already supported this in my signature xD

Support for both this and

(color at [sprite v] :: sensing)

The one with coordinates would simply pick the colour at the coordinates you give. The one with a sprite would pick the colour at the sprite's centre, but it would pick up the colour of the layer under the sprite, rather than the sprite itself.

Oh, I like that idea; however the wording is confusing. Maybe it should be

(color below [Sprite1 v]'s center::sensing)

I for one would prefer

([color under center v] of [Sprite1 v])

.

The following is the least ambiguous implementation.

(colour at x: (0) y: (0) :: sensing)

support
EDIT: What if the sprite was touching more than one colors? Would it return nothing?

Ninkancho wrote:

Sheep_maker wrote:

stickfiregames wrote:

Sheep_maker wrote:

…

Support for both this and

(color at [sprite v] :: sensing)

The one with coordinates would simply pick the colour at the coordinates you give. The one with a sprite would pick the colour at the sprite's centre, but it would pick up the colour of the layer under the sprite, rather than the sprite itself.

Oh, I like that idea; however the wording is confusing. Maybe it should be

(color below [Sprite1 v]'s center::sensing)

I for one would prefer

([color under center v] of [Sprite1 v])

Would the sprite dropdown also include “myself” or the sprites own name?

I was thinking (color under center) and (color at x: () y: ()) could be separate blocks, seeing as the sensing (() of ()) doesn't include the sprite in question.

Support, but would be complicated if the costume was made in vector.

banana439monkey wrote:

Support, but would be complicated if the costume was made in vector.

How? It too will have a 1 pixel center no matter how big or small it is… I mean the center doesn't change size.

banana439monkey wrote:

Support, but would be complicated if the costume was made in vector.

How?

banana439monkey wrote:

Support, but would be complicated if the costume was made in vector.

I'm guessing that it would act as if the vector costume was converted into bitmap/stamped.

bump

⬆⬆⬆

maybe instead

([color v] effect :: looks)

banana439monkey wrote:

maybe instead

([color v] effect :: looks)

THAT'S EXACTLY WHAT I WANT!!!!

Sheep_maker wrote:

Support for

(color at x:(0) y:(0)::sensing) // updates to your current position

Don't suggest this! It is already suggested.
And the color should be reported in decimal (0-16777215) which is compatible with the Scratch color inputs.

Btw I already supported this in my signature xD

Support this idea because then you are able to find the colour at a location without having to move a sprite. Should be quicker then if you want to store a “screenshot” of a screen

⏫

Gaza101 wrote:

The following is the least ambiguous implementation.

(colour at x: (0) y: (0) :: sensing)

O rly?!

So… does it ignore the costume of the sprite that's executing this block? (Like the ‘touching color’ block does, so it detects the colour without this sprite) …or does it include the costume of this sprite?

If the latter then you have to be sure to hide the current sprite (if it's not blank and has part of its costume over the relevant point) in order to get the colour under the sprite. If the former then it means each sprite can potentially give a different result for the same co-ordinates.

I'm curious to know which of those two people here would expect…?

Not that I wouldn't like to see this block, mind… just askin'… :)

How will different sprites give different colors for same coords? It is supposed to global so reports the color of the image that is at the top most layer/ colors we see on screen (so it will only report colors we see).

P444 wrote:

How will different sprites give different colors for same coords? It is supposed to global so reports the color of the image that is at the top most layer/ colors we see on screen (so it will only report colors we see).

Exactly!

So you'd expect the latter case. I'd imagine many would.

But the “touching color” block ignores the current sprite's costume (for obvious reasons!), so I'm wondering if anyone might think this block would too…? (I mean, if you have the sprite visible, and you ask what colour is at a position that's covered by this sprite's costume, is there anyone out there who would expect this block to report what's ‘under’ the sprite, rather than the sprite itself? I think it's possible some could expect this behaviour, so I was questioning Gaza101's claim that it was not so ambiguous…)

Ninkancho wrote:

I was thinking (color under center) and (color at x: () y: ()) could be separate blocks, seeing as the sensing (() of ()) doesn't include the sprite in question.

Well, (color under center) would be (color at x: (x position) y: (y position))