A pen canvas would be an advanced option for the pen/stamp tool.

This feature would work something like this:

You would create canvases similarly to how you would create variables and lists aka:

Make a Canvas ::reporter #cccccc ring //sorry for the bad depiction of the button


switch to canvas: [canvas1 v] ::pen //allows you to switch to a particular canvas for editing
clear [canvas1 v] ::pen //clears selected canvas (also includes options all and current)
show canvas [canvas1 v] ::pen //would display selected canvas (also includes options all and current)
hide canvas [canvas1 v] ::pen //would stop displaying selected canvas (also includes options all and current)
bring [canvas1 v] to front ::pen //would shift the selected canvas to the front(also includes options current)
move [canvas1 v] to layer (1 v) ::pen //would reorder the canvases (also includes options current)
copy pen from [canvas1 v] to [canvas2 v] :: pen //would copy all of the information from one canvas to another
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
apply effect [pixelate v] to [canvas1 v] ::pen //would allow for all graphic effects to be applied to selected canvas
clear effects form [canvas1 v] ::pen //clears effects from canvas
set pen mode to [erase v] ::pen //as we are delving into layered canvases, it would probably be important to have an eraser as well to support transparency

• All normal pen based features would still work, but it would place the things on the current canvas.
  
• The canvases would operate completely separately from each other, but can display all at the same time.
  
• Any sprite would be able to interact with any canvas, (unless ‘for this sprite only’ is selected)
  
• This would allow people to easily create pen based games without the need for redrawing all objects for each frame
  
• You would have the ability to copy one canvas over another.
  
• You could use the show/hide all ability to make ‘scenes’ upon which many sprites operate.
  

Another thing, canvases should be able to be moved around.

set size of [canvas1 v] to () :: pen 
move [canvas1 v] to x: () y: () :: pen 

(canvas x ::pen)
(canvas y ::pen)
([name of active canvas v] of [sprite v]
([x position v] of canvas[canvas1 v] ::pen)
([y position v] of canvas[canvas1 v] ::pen)
([size v] of canvas[canvas1 v] ::pen)

A bit unrelated to pen canvases at the moment, but still good to mention as it is extremely easy to implement:

<is pen down? ::pen> //Implentation shown here: https://github.com/NitroCipher/scratch-vm/blob/patch-1/src/extensions/scratch3_pen/index.js

If you support this addition I will add you to the list below

TheKnewGreg: Full Support
stickfire-test: Full Support (suggested the addition of canvas layering)
jromagnoli: Semi Support
WolfCat67: Full Support (suggested block formatting for canvas copying)
Nerdy402: Full Support
duckboycool: Full Support
stickfiregames: Full Support
Scratcher1002: Full Support
Blaze349: Full Support
Sheep_maker: Full Support
AlexandreGharbi: Full Support
Greenduck54: Full Support
AmazingMech2418: Full Support
Scooperax: Full Support
MrFlightless: Full Support
0037318: Full Support
asdf1qwer3: Full Support
Flipped_: Full Support
Scratch_Foxy_Rogues: Support for more advanced users
Monniasza_spzoo: Full Support
scratchDefender: Full Support
WaterComesBack: Full Support

Changelog:
6th June, 2017: Added canvas motion
8th June, 2017: Added ability for one canvas to copy over another
31st August, 2017: Added ability to show/hide sprites on canvas
30th January, 2018: Added graphic affects to canvases
24th January, 2019: Added <is pen down?> block
1st September, 2019: Added eraser pen mode block, updated support list

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

Support.

How would it decide how to order the canvases? Would you be able to change the order in the editor, or have extra blocks to set the order?

Maybe it would be better to have “pen layers”, and the blocks would be like this but with a number input instead of a dropdown - that way, it could just have layer 1 on top, layer 2 behind it etc.

stickfire-test wrote:

Support.

How would it decide how to order the canvases? Would you be able to change the order in the editor, or have extra blocks to set the order?

Maybe it would be better to have “pen layers”, and the blocks would be like this but with a number input instead of a dropdown - that way, it could just have layer 1 on top, layer 2 behind it etc.

I will add the ordering suggestion to the block list. Thanks for the support and the idea!

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

NitroCipher wrote:

A pen canvas would be an advanced option for the pen/stamp tool.

This feature would work something like this:

You would create canvases similarly to how you would create variables and lists aka:

Make a Canvas ::reporter #cccccc ring //sorry for the bad depiction of the button


switch to canvas: [canvas1 v] ::pen //allows you to switch to a particular canvas
clear [canvas1 v] ::pen //clears selected canvas (also includes options all and current)
show canvas [canvas1 v] ::pen //would display selected canvas (also includes options all and current)
hide canvas [canvas1 v] ::pen //would stop displaying selected canvas (also includes options all and current)
bring [canvas1 v] to front ::pen //would shift the selected canvas to the front(also includes options current)
move [canvas1 v] to layer (1 v) ::pen //would reorder the canvases (also includes options current)

• All normal pen based features would still work, but it would place the things on the current canvas.
  
• The canvases would operate completely separately from each other, but can display all at the same time.
  
• Any sprite would be able to interact with any canvas, (unless ‘for this sprite only’ is selected)
  
• This would allow people to easily create pen based games without the need for redrawing all objects for each frame
  

If you support this addition I will add you to the list below

TheKnewGreg: Full Support
stickfire-test: Full Support (suggested the addition of canvas layers)

I think this is a duplicate or near duplicate of a topic I have seen. Can someone help me out here?
Also the amount of data to be stored would lag the project horribly.

jromagnoli wrote:

NitroCipher wrote:

-snip-

I think this is a duplicate or near duplicate of a topic I have seen. Can someone help me out here?
Also the amount of data to be stored would lag the project horribly.

The amount of lag would be dependent on the number of layers, and a project without these blocks wouldn't lag any more than projects do now. I don't think it would lag too much until you had quite a lot of layers, but if necessary there could be a limit like there is with clones.

You might be thinking of a suggestion a few weeks ago for being able to clear individual sprites' pen trails. That would require loads of layers which really would lag the project, and I think someone suggested this (but not as a new topic, just a replay to that one) as a way to counter that.

stickfiregames wrote:

jromagnoli wrote:

NitroCipher wrote:

-snip-

I think this is a duplicate or near duplicate of a topic I have seen. Can someone help me out here?
Also the amount of data to be stored would lag the project horribly.

The amount of lag would be dependent on the number of layers, and a project without these blocks wouldn't lag any more than projects do now. I don't think it would lag too much until you had quite a lot of layers, but if necessary there could be a limit like there is with clones.

You might be thinking of a suggestion a few weeks ago for being able to clear individual sprites' pen trails. That would require loads of layers which really would lag the project, and I think someone suggested this (but not as a new topic, just a replay to that one) as a way to counter that.

Yes, I just found the topic and I was wrong.

jromagnoli wrote:

Also the amount of data to be stored would lag the project horribly.

…Are you sure?

The Scratch screen is 480px * 360px, and the pen canvas clearly uses this as its resolution - i.e. it doesn't scale up nicely when in full screen mode, meaning it's just using the same 480 * 360 image.

A 480 * 360 full-argb image is 691200 bytes - or 691k. That is somewhat large, but it is not particularly large; quite a few layers could be made before it really got to be a problem.

That is also assuming that each layer wouldn't be compressed in any way, which is unlikely. Even if each image just bounded the space it was using to draw, the size would be significantly reduced in a lot of situations.

EDIT: Ninja'd.

TheMonsterOfTheDeep wrote:

jromagnoli wrote:

Also the amount of data to be stored would lag the project horribly.

…Are you sure?

The Scratch screen is 480px * 360px, and the pen canvas clearly uses this as its resolution - i.e. it doesn't scale up nicely when in full screen mode, meaning it's just using the same 480 * 360 image.

A 480 * 360 full-argb image is 691200 bytes - or 691k. That is somewhat large, but it is not particularly large; quite a few layers could be made before it really got to be a problem.

That is also assuming that each layer wouldn't be compressed in any way, which is unlikely. Even if each image just bounded the space it was using to draw, the size would be significantly reduced in a lot of situations.

EDIT: Ninja'd.

Hey Monster, do you want me to add you to the support list?

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

jromagnoli wrote:

stickfiregames wrote:

jromagnoli wrote:

NitroCipher wrote:

-snip-

I think this is a duplicate or near duplicate of a topic I have seen. Can someone help me out here?
Also the amount of data to be stored would lag the project horribly.

The amount of lag would be dependent on the number of layers, and a project without these blocks wouldn't lag any more than projects do now. I don't think it would lag too much until you had quite a lot of layers, but if necessary there could be a limit like there is with clones.

You might be thinking of a suggestion a few weeks ago for being able to clear individual sprites' pen trails. That would require loads of layers which really would lag the project, and I think someone suggested this (but not as a new topic, just a replay to that one) as a way to counter that.

Yes, I just found the topic and I was wrong.

Hey Jromagnoli, do you want me to add you to the support list?

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

NitroCipher wrote:

jromagnoli wrote:

stickfiregames wrote:

jromagnoli wrote:

NitroCipher wrote:

-snip-

I think this is a duplicate or near duplicate of a topic I have seen. Can someone help me out here?
Also the amount of data to be stored would lag the project horribly.

The amount of lag would be dependent on the number of layers, and a project without these blocks wouldn't lag any more than projects do now. I don't think it would lag too much until you had quite a lot of layers, but if necessary there could be a limit like there is with clones.

You might be thinking of a suggestion a few weeks ago for being able to clear individual sprites' pen trails. That would require loads of layers which really would lag the project, and I think someone suggested this (but not as a new topic, just a replay to that one) as a way to counter that.

Yes, I just found the topic and I was wrong.

Hey Jromagnoli, do you want me to add you to the support list?

Sure, but as a semi supporter.

jromagnoli wrote:

Sure, but as a semi supporter.

What part do you object to?

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

NitroCipher wrote:

jromagnoli wrote:

Sure, but as a semi supporter.

What part do you object to?

I'm not 100% sure on this, so I want to be marked as semi support until I am 100% sure.

This would probably be super useful! Originally I thought it was a duplicate of the pen layers suggestion, until I realized there was so much more you could do with these “canvases”.
May I also suggest these extra blocks?

set size of [canvas1 v] to () :: pen // Size, by default, would be 100; would work similar to a sprite.

move [canvas1 v] to x: () y: () :: pen // If the size is added, it would make sense to move the pen as well, right?

WolfCat67 wrote:

This would probably be super useful! Originally I thought it was a duplicate of the pen layers suggestion, until I realized there was so much more you could do with these “canvases”.
May I also suggest these extra blocks?

set size of [canvas1 v] to () :: pen // Size, by default, would be 100; would work similar to a sprite.

move [canvas1 v] to x: () y: () :: pen // If the size is added, it would make sense to move the pen as well, right?

These would be somewhat nice, but they do not conform well to how scratch operates. Unfortunately because of this, I will not be adding this to the block list. The scratch team would have to make the size of the current canvas be much larger and operate differently to do this.

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

NitroCipher wrote:

WolfCat67 wrote:

This would probably be super useful! Originally I thought it was a duplicate of the pen layers suggestion, until I realized there was so much more you could do with these “canvases”.
May I also suggest these extra blocks?

set size of [canvas1 v] to () :: pen // Size, by default, would be 100; would work similar to a sprite.

move [canvas1 v] to x: () y: () :: pen // If the size is added, it would make sense to move the pen as well, right?

These would be somewhat nice, but they do not conform well to how scratch operates. Unfortunately because of this, I will not be adding this to the block list. The scratch team would have to make the size of the current canvas be much larger and operate differently to do this.

Hmm… They would not exactly have to make the current canvas much larger, because of the fact that it could work similarly to a sprite; a sprite's able to cover an entire page and then go up to a specific point before it can get any larger. However, I do agree that the canvases would have to work quite differently, and it would pretty much turn into “pen-drawn sprites”… I still support the suggestion, though.

WolfCat67 wrote:

NitroCipher wrote:

WolfCat67 wrote:

This would probably be super useful! Originally I thought it was a duplicate of the pen layers suggestion, until I realized there was so much more you could do with these “canvases”.
May I also suggest these extra blocks?

set size of [canvas1 v] to () :: pen // Size, by default, would be 100; would work similar to a sprite.

move [canvas1 v] to x: () y: () :: pen // If the size is added, it would make sense to move the pen as well, right?

These would be somewhat nice, but they do not conform well to how scratch operates. Unfortunately because of this, I will not be adding this to the block list. The scratch team would have to make the size of the current canvas be much larger and operate differently to do this.

Hmm… They would not exactly have to make the current canvas much larger, because of the fact that it could work similarly to a sprite; a sprite's able to cover an entire page and then go up to a specific point before it can get any larger. However, I do agree that the canvases would have to work quite differently, and it would pretty much turn into “pen-drawn sprites”… I still support the suggestion, though.

I agree that it would be highly useful, and I would love to see it implemented. I just think that after a certain point it just becomes to complicated.

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

Bump

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

I have a question: What happens if you use pen without creating a canvas layer first? Would it just treat that as a new layer called “stage”?

WolfCat67 wrote:

I have a question: What happens if you use pen without creating a canvas layer first? Would it just treat that as a new layer called “stage”?

That is exactly what would happen. Great question though!

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

WolfCat67 wrote:

I have a question: What happens if you use pen without creating a canvas layer first? Would it just treat that as a new layer called “stage”?

How about there's a background canvas that can't be deleted, effectively the backdrop equivalent?

Sigton