Support! This would be really useful as compared to grouping all drawings as one!

One thing -

NitroCipher wrote:

show all sprites on [canvas1 v] :: pen //would show all sprites that are tied to the selected canvas
hide all sprites on [canvas1 v] :: pen //would hide all sprites that are tied to the selected canvas

I don't think this is really necessary. It wouldn't be that useful - there are easy workarounds to it, such as using a list to store the sprites tied to a canvas.

I haven't used the forums in a while and posted the same thing twice, and I have no idea how to delete this

when green flag clicked
say [RUN!!!!!]
set [realization] to [1]
say [false alarm! it's just a kumquat! you're all safe!]
say [i saved you guys from this deadly kumquat!]

My apologies if there are any rules against commenting on old posts - I looked and couldn't find any, and I don't want to create a duplicate topic, which I know is against the rules. see bottom of post

I also find that having multiple layers of pen could be quite useful, and add features that can't be (easily) worked around otherwise. However, I disagree with this particular implementation, for several reasons:

1 - this is a fairly minor complaint, but I feel that “layers” would suit this effect more than “canvases”
2 - certain features appear to make things too easy; one could work around quite a few of these blocks without too much difficulty, if given a few basic ones.
examples:
both of the following blocks

show canvas [canvas1 v] ::pen
hide canvas [canvas1 v] ::pen

can be worked around by either using the clear block (for hiding) or by simply re-drawing its contents (showing)

these two

bring [canvas1 v] to front ::pen
move [canvas1 v] to layer (1 v) ::pen

are highly unnecessary, as you can just re-order the contents you wish to draw to the proper layers; Also, reordering numbered canvases would get confusing, especially when canvas 1 ends up between 2 and 3

this one

copy pen from [canvas1 v] to [canvas2 v] ::pen

is likely to cause a LOT of lag, and is, again, unnecessary

the following I feel are all just confusing and either unintuitive, or reproducible without even using pen

show all sprites on [canvas1 v] ::pen
hide all sprites on [canvas1 v] ::pen
apply effect [pixelate v] to [canvas1 v] ::pen
clear effects from [canvas1 v] ::pen

3:
It is my own opinion that these canvases should have a fixed position and size, and should be writable by any sprite.

4: the “is pen down” operator is fairly redundant, as one can set a variable to true when they set the pen to be down, and false when they pick the pen back up.





~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So then, if I were to make this particular extension, I would have the following blocks added from the original post:

switch to canvas: [canvas1 v] ::pen
clear [canvas1 v] ::pen

as well as, if at all possible, some implementation of an eraser. Because we are now working with layers and, therefore, transparency, simply drawing white will no longer work to erase, as there would now be a white streak on that portion of the canvas. I suggest something that uses basically the same script as the pre-existing pen blocks (size and maybe transparency) and add the following two blocks in:

eraser down ::pen
eraser up ::pen

these would function exactly the same as the pen down and pen up blocks, but, instead of leaving a trail of a certain color, they would replace all the pixels with either A: blank, fully transparent pixels, or B: if transparency is given to the eraser, slightly more transparent versions of the pixels in its path.


Layers would be static, and layered so that the lower numbers get rendered closer to the front; layer 5 would be in the back, then 4, then 3, then 2, then 1, then sprites, then speech bubbles/variables, etc, etc.
Users can specify which layer to draw to before they put the pen down, and anything drawn would apply to that layer until the layer is changed. Sprites do not have to be bound to specific layers.
Old projects that don't specify layers would simply use layer 1.
projects default to only using a single layer, with the option to “add a new layer” appearing in the drop-down when selecting a layer to draw to.
To save on lag if the simple act of having pen layers is too much for certain devices, a cap could be put on the maximum number of layers (4 or more seems workable for most games (background, foreground, effect (think pokemon caves where you need to use flash), and UI))


These suggestions make the additions both more intuitive to work with (especially for people who have worked with any image editors or decent art programs), less laggy (copying canvases is not going to be the fastest operation scratch can do), and easier to implement (as there are just less features in general)


edit: ok so It's been a /reeeally/ long time since I used the forums, and I didn't see that you can switch pages, and I'm not the only one who posted this year. That's nice to know

when green flag clicked
say [RUN!!!!!]
set [realization] to [1]
say [false alarm! it's just a kumquat! you're all safe!]
say [i saved you guys from this deadly kumquat!]

With Pen being an extension now, would it make sense to have this as some kind of pen-extension-extension?

I think having multiple pen layers is a good idea, even if the particular implementation described has a few issues (as argued above). I like the idea of there being some slightly more advanced extensions like this for users who want to do even more with Scratch.

Support! It will allow more complex graphics.

Support. Although, how Scratch VM interacts with the canvas is beyond me and I'm wondering whether two canvases would be possible. It's certainly possible to have multiple canvases, but would the Scratch GUI be able to place two canvases? I'll do some studying on the pen blocks.

I do not really understand this suggestion.

Could someone please elaborate?

I think that since canvases are any size, they need 0 0 as top left

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██░▄▄░██▄██░▄▀▄░█░▄▀▄░█░▄▄███░▄▄▀█░▄▄▀████▄██░▄▄▀█▄░▄█░▄▄█░▄▄▀█░▄▄▀█░▄▄█▄░▄
██░█▀▀██░▄█░█▄█░█░█▄█░█░▄▄███░▀▀░█░██░████░▄█░██░██░██░▄▄█░▀▀▄█░██░█░▄▄██░█
██░▀▀▄█▄▄▄█▄███▄█▄███▄█▄▄▄███▄██▄█▄██▄███▄▄▄█▄██▄██▄██▄▄▄█▄█▄▄█▄██▄█▄▄▄██▄█
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

Nambaseking01 wrote:

I do not really understand this suggestion.

Could someone please elaborate?

Hi King Nammy, what part do you need help with?

Current project: [s3Blocks: scratchblocks rewritten for Scratch 3.0] ::#4b4a60 //https://scratch.mit.edu/discuss/topic/290031/ Basically done!

NitroCipher wrote:

-snip-
Hi King, what part do you need help with?

So what are the things we put into this canvas and how do we decorate them?

By the way, please call me Nammy — that is my online nickname.

Nambaseking01 wrote:

NitroCipher wrote:

Hi King, what part do you need help with?

So what are the things we put into this canvas and how do we decorate them?

By the way, please call me Nammy — that is my online nickname.

You draw on the canvases in the same way you would the pen tool. This idea is just an expansion upon that general idea.

Current project: [s3Blocks: scratchblocks rewritten for Scratch 3.0] ::#4b4a60 //https://scratch.mit.edu/discuss/topic/290031/ Basically done!

bump
Bouncy
Underscores
Making
Pizza

move (999999999) steps
move (999999) steps

Update bump!

Current project: [s3Blocks: scratchblocks rewritten for Scratch 3.0] ::#4b4a60 //https://scratch.mit.edu/discuss/topic/290031/ Basically done!

Support! I see many uses in this!

Sorry for being so late in this interesting discussion.

As I understand it, the final goals of this extension are:

• easily create pen based games without the need for redrawing all objects for each frame
  
• use the show/hide all ability to make ‘scenes’ upon which many sprites operate.
  

Would the Snap ability of creating costumes from pen trails do the job? You can see it at https://snap.berkeley.edu/snap/snap.html#present:Username=s_federici&ProjectName=creating%20costumes%20(short). Would there be something still missing?

I support this, it would honestly make my life a lot easier.

when I receive [Endless-Ocean Supports This]
add [Endless-Ocean] to [Support List]

wait until <(the world is flat?) = [true]>

Endless-Ocean wrote:

I support this, it would honestly make my life a lot easier.

when I receive [Endless-Ocean Supports This]
add [Endless-Ocean] to [Support List]

Please don't necropost. The latest reply was from more than a year ago, so I don't think it would have been a good idea to necropost.
Please check the latest post's date to see if you should necropost/bump it or not.
EDIT: Not a necropost, since this contributes to the topic. Sorry!

move (999999999) steps
move (999999) steps

full support assuming this is antother extenstion that way no one can say it's too complex for scratch

Bump.

I will bet that there are a lot of people that would want this!