When I try to use the "touching __ color" block on something really thin, it oftens gets it wrong because thin things tend to be a shade lighter, while also being really hard to click exactly. Is there a way I can pull up a list or something that shows me what colors the sprite currently is touching, so I can just select it from there?
Alternative might be to point resize your sprite costume to make it easier to select a colour
Didn't work, but thanks for trying
You can use ([RGBA V] at [[myself] V]) to get the color at the rotation center of the sprite.
I decided to try and see if I can create a script in snap to get all the colors the sprite it touching, while also ignoring fully transparent pixels, but it turns out that doing it in snap is unusably slow, but I'll still share what I tried anyway.
I found out that the ([RGBA V] at [ V]) is hyperized, so I could just stick the entire grid of positions in the sprite's bounding box to get the colors. But first I needed to get the grid, so I created this block.
I did it this way with flooring the width and height due to trying to normalize rounding. I also chose to do it with the width and height instead of the left and right, because I was getting a grid that was one pixel larger than the width and height.
Next I went to get a grid of all the opaque pixels (or transparent pixels), so I made this block.
Since I want to handle rotation without having to transform the costume, I opted to just blacking out the costume, then pasting it on a white sprite that was the same size as the sprite. Then I just went though the pixels of that result to exclude all the white pixels (I needed to add a bit of tolerance because for some reason some pixels weren't completely white).
After doing all that, I can then combine them all into this block
In this block I make sure to hide the sprite before grabbing the colors, so that the result does not include any colors on the sprite. To ignore opaque pixels, I just multiply the resulting grid of colors with the opaque pixels grid (which is a grid of true/false), which will just zero out all the fully transparent pixels.
This script should theoretically work, but I was unable to even get a result because it just freezes snap, at least on the test costume I was using. If I can speed up getting the color at a specific location, then it could work. That's really the only issue, and why this is not useable for practical use.
That's still really interesting, thanks
I've figured out a few optimizations here.
Nested maps are never good for efficiency. Of course, this optimization will only help if you already can handle larger dimensions (which your version cannot). I used the hidden "transpose" function to create my own version (btw I have not tested this for speed, I'm assuming its faster based on past experience):
I'm pretty sure there's a way to use combinations as well.
This one is the biggy. You are looking at every pixel within the rectangular extent of the costume and then removing the pixels that aren't in the costume. This means a diagonal line will take exponentially longer than a vertical or horizontal one. If you remove those coordinates from the position grid first, speed can increase drastically (not on rectangular costumes though). I also tweaked a couple blocks to help this process (2D instead of 3D lists).
In this test (black sprite is detecting), the original version broke Snap, but the optimized version took "only" 50 seconds:
PS: I haven't tried optimizing the "get opaque pixels" block, because initially I forgot about allowing for rotation and did this:
I suppose that this could be used as a faster method for cases where the sprite isn't rotated...
I'll probably continue trying to optimize this (although there is, of course, a limit to what I, or anybody else not using JavaScript extensions other than jens, can do).
For this scenario:
- blue line at the center of ther Stage
- green oval Sprite1
You may use this script to get pixels of the stage that overlaps with the sprite
But there is a problem with the antialiasing. Cutting the same costume leaves a small residue.
Building off of this, I created this:
Near instantaneous in my tests.
Yea, built-ins are fast, but the remaining part of the sprite (pointed by the green arrow) is falsely reported ;(
I have updated this block to check for hidden sprites and to detect transparent pixels properly (the stage looks white, but is really "transparent"). Here it is:
Edit:
I made the block so that it would only report fully opaque pixels, and this solves that problem.
Removed, because I was wrong (I was smarter than I thought when I designed the first version.
However, I'm realizing that that means that deliberately semi-transparent pixels in a costume won't detect. Here is an updated version that removes the edge pixel detections but should work for semitransparent costumes.
Mini-necroing?
I think that topics close after a month (30 days) because posting before then should be fine, particularly when adding to a topic (in my case, fixing a couple bugs). I suppose I could have edited the previous post I made though.
Necroposting refers to posting in a really old topic while not adding anything relevant in it
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.