Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

“If the human eye can’t tell the difference”
How do you quantify that?
There’s no destiction between what is “green” and what isn’t
All the computers sees is #528a42 and #609e4f (these are very slightly different shades of green, see how much of a difference they have?)
It doesn’t know what is green
The color slider is just a fancy way to edit this number

I think computers should be capable of knowing whether a color is close enough so that a human eye wouldn't be able to distinguish it.

The computer isn’t a human therefore it doesn’t know
Computers don’t see “color” they just see #4287f5 and roll with it as they are told
The computer just renders it as color but the computer has no way of interpreting color as, well, color

It's still possible, just make it so that it senses whether the Color, Saturation, and Darkness are close or not. I'm sure Scratch can even come up with a way better way to achieve this. Computers are capable of more than meets the eye (see what I did there?)

Saturation and darkness come from the hex value
Also you literally said color

Color, Saturation, and Darkness are the values you input into Scratch. As said in the original post, even getting these values exactly right can still not work a lot of the time

Then use the color picker

What would happen to the projects that depend on this block then? They'd break, that's what.

Elijah999999 wrote:

What would happen to the projects that depend on this block then? They'd break, that's what.

Yea

It’s too late to make changes to a block like this

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

HAL95131 wrote:

Also, yes, I feel like they could maybe use RGB values to check similarity between colors?

That would break projects because the block uses hex color codes and you can do

<touching color (join [#] [099e99]) ?>

To bypass that, this is used quite often

Also the paint editor supports an alpha/transparency Chanel, this works with the touching color block as well
It’s better to just do

<<touching color [#099e99] ?> or <touching color [#659e80] ?>>

Or not use the block at all because of how slow it is

Why is it there if it's so broken? It really should be improved because it can be so useful in many situations

Because it looks at the entire screen instead of just within the sprites bounding box

Flash used to do this, it would see if the color is inside of the sprites bounding box (that is the box that extends to the top, bottom, left, and right of the sprite) and then after it sees if the sprites pixels are touching the color looking at just the bounding box, not the entire screen. Because a sprite’s pixels will always be within its bounding box. This incressed the speed of flash games significantly!

Wait, I don't get how this helps ur point

With my past experiences with this block, there was a small discrepancy between each of the values of the color.

Support because of reasons in OP. It should be a separate block though.

<touching similar color to [#eb0e0e] ? ::sensing>

The workaround is a little bit complicated.

1. Take RGB as an input
2. Test the values using a small range between those numbers and the <touching color ?> block
3. Return true if any match

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

“If the human eye can’t tell the difference”
How do you quantify that?
There’s no destiction between what is “green” and what isn’t
All the computers sees is #528a42 and #609e4f (these are very slightly different shades of green, see how much of a difference they have?)
It doesn’t know what is green
The color slider is just a fancy way to edit this number

I think computers should be capable of knowing whether a color is close enough so that a human eye wouldn't be able to distinguish it.

The computer isn’t a human therefore it doesn’t know
Computers don’t see “color” they just see #4287f5 and roll with it as they are told
The computer just renders it as color but the computer has no way of interpreting color as, well, color

It's still possible, just make it so that it senses whether the Color, Saturation, and Darkness are close or not. I'm sure Scratch can even come up with a way better way to achieve this. Computers are capable of more than meets the eye (see what I did there?)

Saturation and darkness come from the hex value
Also you literally said color

Color, Saturation, and Darkness are the values you input into Scratch. As said in the original post, even getting these values exactly right can still not work a lot of the time

Then use the color picker

I did, but the color picker is even worse

ajskateboarder wrote:

Support because of reasons in OP. It should be a separate block though.

<touching similar color to [#eb0e0e] ? ::sensing>

The workaround is a little bit complicated.

1. Take RGB as an input
2. Test the values using a small range between those numbers and the <touching color ?> block
3. Return true if any match

True, or they could add the “sensing leeway” block suggestion from earlier

ajskateboarder wrote:

Support because of reasons in OP. It should be a separate block though.

<touching similar color to [#eb0e0e] ? ::sensing>

The workaround is a little bit complicated.

1. Take RGB as an input
2. Test the values using a small range between those numbers and the <touching color ?> block
3. Return true if any match

Have you seen my ideas as well? I would like to see your thoughts on the blocks I made.

HAL95131 wrote:

ajskateboarder wrote:

Support because of reasons in OP. It should be a separate block though.

<touching similar color to [#eb0e0e] ? ::sensing>

The workaround is a little bit complicated.

1. Take RGB as an input
2. Test the values using a small range between those numbers and the <touching color ?> block
3. Return true if any match

Have you seen my ideas as well? I would like to see your thoughts on the blocks I made.

Sure

I think they should just add something like:

touching color close to [#bf1a48] ? :: sensing boolean

so that it would not break projects who use the block with exactness
so, kinda support

No support, just make your sprites solid colors and thick enough for interpolation to not mess it up

glomeromycota wrote:

No support, just make your sprites solid colors and thick enough for interpolation to not mess it up

Seems kinda forced

HAL95131 wrote:

ajskateboarder wrote:

Support because of reasons in OP. It should be a separate block though.

<touching similar color to [#eb0e0e] ? ::sensing>

The workaround is a little bit complicated.

1. Take RGB as an input
2. Test the values using a small range between those numbers and the <touching color ?> block
3. Return true if any match

Have you seen my ideas as well? I would like to see your thoughts on the blocks I made.

I'm not the OP, but your blocks are probably better since you can specify the range, and there aren't any breaking changes

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

“If the human eye can’t tell the difference”
How do you quantify that?
There’s no destiction between what is “green” and what isn’t
All the computers sees is #528a42 and #609e4f (these are very slightly different shades of green, see how much of a difference they have?)
It doesn’t know what is green
The color slider is just a fancy way to edit this number

I think computers should be capable of knowing whether a color is close enough so that a human eye wouldn't be able to distinguish it.

The computer isn’t a human therefore it doesn’t know
Computers don’t see “color” they just see #4287f5 and roll with it as they are told
The computer just renders it as color but the computer has no way of interpreting color as, well, color

It's still possible, just make it so that it senses whether the Color, Saturation, and Darkness are close or not. I'm sure Scratch can even come up with a way better way to achieve this. Computers are capable of more than meets the eye (see what I did there?)

Saturation and darkness come from the hex value
Also you literally said color

Color, Saturation, and Darkness are the values you input into Scratch. As said in the original post, even getting these values exactly right can still not work a lot of the time

Then use the color picker

I did, but the color picker is even worse

The color click on the middle of the color, the edges are changed due to anti aliasing

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

Dodger380468 wrote:

cookieclickerer33 wrote:

“If the human eye can’t tell the difference”
How do you quantify that?
There’s no destiction between what is “green” and what isn’t
All the computers sees is #528a42 and #609e4f (these are very slightly different shades of green, see how much of a difference they have?)
It doesn’t know what is green
The color slider is just a fancy way to edit this number

I think computers should be capable of knowing whether a color is close enough so that a human eye wouldn't be able to distinguish it.

The computer isn’t a human therefore it doesn’t know
Computers don’t see “color” they just see #4287f5 and roll with it as they are told
The computer just renders it as color but the computer has no way of interpreting color as, well, color

It's still possible, just make it so that it senses whether the Color, Saturation, and Darkness are close or not. I'm sure Scratch can even come up with a way better way to achieve this. Computers are capable of more than meets the eye (see what I did there?)

Saturation and darkness come from the hex value
Also you literally said color

Color, Saturation, and Darkness are the values you input into Scratch. As said in the original post, even getting these values exactly right can still not work a lot of the time

Then use the color picker

I did, but the color picker is even worse

The color click on the middle of the color, the edges are changed due to anti aliasing

Even then, it doesn't work a lot of the time