Now "paste on" block (that makes "a print" of one sprite on another sprite) can make it in the only way: this "print" will appear on non transparent area of the sprite being printed on. And that's all. This block uses CanvasRenderingContext2D.drawImage() method with CanvasRenderingContext2D.globalCompositeOperation property hardcoded to 'source-atop' value.
But there is a lot of other values of globalCompositeOperation that can make drawImage() to work in very different and interesting ways! Here is the list of these values and illustrations of their effects: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation Look, they allow to multiply, subtract and merge sprites in different ways, it's so cool!
That's why I ask @jens to make it possible to choose globalCompositeOperation type for "paste on" block. @dardoro proposed something like this:
Jens said It's overburdened. Ok, it may be a partly hidden feature like 'pen vectors' block: it's not present in main blocks toolkit and available only when right-clicking on 'pen trails' block.
I'm almost certainly never going to add this drop-down, because it's precisely the kind of thing that will make Snap inexplicably hard to understand for our target audience. What we've been considering instead is an "erase" mode, in which all pen actions would ... well, erase ... instead of add to the pen trails. Likewise stamping would also erase, and - I guess - "pasting" might erase, too. But you know, then folks will request XOR and all the other combinations, and we're down the usual rap again.
See, yesterday's little challenge how to accomplish "holes" actually lead to at least 3 different solutions, all of which work. There's a design principle I love by which easy things should be easy, and hard things possible. By adding settings, choices, preferences and parameters we're making hard things easier, but also easy things harder. That's why I'm leaving them out. Design is ... contrary to what most programmers believe ... about deciding which features to leave out, and less about how to include more.
There is an old Roman adage: there is no harm to the wanter.
So maybe the library with the omnipotent functions with a stripped-down version as a common built-in primitives. There are already quite sophisticated libraries hosted by Snap! with no harm to anyone.
"make Snap inexplicably hard to understand for our target audience."
I think, Snap! already has features that are much harder to understand than image subtraction or multiplication. Especially in libraries. This feature can also exist in enhanced pen library. I do not insist that ALL the globalCompositeOperation values should be available in Snap! Personally, I want 'source-over', 'destination-out' and maybe one or two more... Though I understand that one day someone will ask for 'xor' etc.
But this feature could really allow to build fast and beautiful apps with Snap. Fast AND beautiful.
...at least 3 different solutions, all of which work
...slow and have graphic issues (flickering and green contour around holes)
"erase" mode... "pasting" might erase...
Ok, that's a great thing too. Would love to see it in Snap.
I think when there's an obvious possible generalization of a feature, it should be in a library. I'm with Jens about that.
Are those options the sixteen Boolean functions? It sort of looks like that. If so, there is a teaching opportunity that should be taken, maybe by putting something like "FTTF" (that's the one for XOR) next to the official Web name.
With respect to pen trails, there is a very long history, and I know precisely what we should do: Have options PEN PAINT, PEN ERASE, and PEN REVERSE (xor). These should be orthogonal to PEN UP and PEN DOWN. Pen reverse is very useful when you're drawing an icon or something that you're later going to want to move. If your drawing isn't monochrome, it's a little hard to know what color you'll get by reversing, but it doesn't matter as long as doing it twice restores the previous color.
There's also an issue about anti-aliasing. I hate anti-aliasing, but at the very least, it should be done only on the actual screen display. Snap!'s idea of what's on the stage should be non-anti-aliased.
(Similarly, Jens made a very simple WRITE block without things like fonts and styles. And that was the right thing. But I would look kindly upon a library with more bells and whistles, although really that should be part of the text window feature.)
Also, it would help if we had the totally crucial feature of being able to specify minimum/default/maximum counts for variadic inputs, so we could handle the case 0/0/1 for an option that's ordinarily hidden. Jens doesn't see the crucialness of this, although he's agreed in principle that it'd be useful. And also the ability to have variadic groups of inputs, so you could have a title text hidden with the actual input slot.
Back on topic: I think we can cover all of the globalCompositeOperation settings with the exception of lighter (which doesn't make much sense to me anyway) and then widen the walls some more if we add one more block, so we have both a paste on and a cut from command:
sure, filtering, I get that. But for a costume, filtering (KEEP) won't do, because we don't actually want to delete the overlapping pixels, but just make them transparent. So, again, how would subtracting strings address this?
I don't quite understand how this CUT FROM block should work. How does it perform on the areas where the source sprite (caller of this block) is opaque and the destination sprite (that I choose from the dropdown menu) is transparent?
Checked it. So it's defenitely a useful feature! And it completely solves my initial task with "holes" in sprites and "terrain damaging". It's a good thing for sure.
But I don't understand how are your going to "cover all of the globalCompositeOperation settings with the exception of lighter"? The thing is: you cannot do anything with transparent area of the destination sprite. You can't make them opaque with these PASTE ON and CUT FROM. And it limits it's usefulness.
The way I see it is that transparent parts of a sprite are not just visually transparent - they define the boundary of the sprite that we all use for the touching block.
Given that as a start, then the current action of the paste on block to only operate on non-transparent pixels makes total sense. The visible parts of the sprite ARE the sprite as far as users are concerned.
So changing its behaviour to paste on the non-transparent parts of a sprite isn't a good idea.
Although the proposed cut block could be useful for some projects, I don't think it is worth including it as a default block.
I think having library blocks that do the extra stuff of addition, subtraction, erasing and XOR type operations is the way to proceed
Yes, and for me it's a nice feature: to have the ability to enlarge this "touching" part of the sprite. Though it will be an advanced one, because we'll need to have in mind that this enlargement is anyway restricted by the sprite's initial bounding box. And it may be not so obvious for beginners. It's a drawback for sure.
