thisandagain wrote:

SuperScratchMaker123 wrote:

There's going to be a project size limit for Scratch 3, Im imagining its bigger than Scratch 2's 50MB limit.. So my question is, what's the project size limit for Scratch 3.0?

It will be the same size, but the exciting thing is that we have greatly improved compression in Scratch 3.0 so you should be able to fit bigger / more complex projects with the same number of bytes.

So, when an offline editor comes for 3.0, will it have no size limit? Because it should not have a size limit if it is taking up purely the user's hard drive space.

Mucadush wrote:

I think Scratch should add a Point Towards X Y block

point towards x: (0) y: (0)

I must agree. I felt often the need of this block. So I created a dummy sprite, moved it to X Y and then used Point Towards sprite. It would really be more natural.

Greenduck54 wrote:

thisandagain wrote:

SuperScratchMaker123 wrote:

There's going to be a project size limit for Scratch 3, Im imagining its bigger than Scratch 2's 50MB limit.. So my question is, what's the project size limit for Scratch 3.0?

It will be the same size, but the exciting thing is that we have greatly improved compression in Scratch 3.0 so you should be able to fit bigger / more complex projects with the same number of bytes.

So, when an offline editor comes for 3.0, will it have no size limit? Because it should not have a size limit if it is taking up purely the user's hard drive space.

Even if there is no size limit in offline editor, it can't be a solution.
Because it is not applicable to "Imagine, Program, Share".

This is the project I concern about. https://scratch.mit.edu/projects/161762297/

I think this can be an instance of “Wide Walls”.
If you look at this project, you must recognize the quality and quantity of it, and the reason why I need extending the limit.

Unfortunately, this project size is almost 50MB.
Due to the size limit, I can't continue extending this project any more.

inoking wrote:

Greenduck54 wrote:

thisandagain wrote:

SuperScratchMaker123 wrote:

There's going to be a project size limit for Scratch 3, Im imagining its bigger than Scratch 2's 50MB limit.. So my question is, what's the project size limit for Scratch 3.0?

It will be the same size, but the exciting thing is that we have greatly improved compression in Scratch 3.0 so you should be able to fit bigger / more complex projects with the same number of bytes.

So, when an offline editor comes for 3.0, will it have no size limit? Because it should not have a size limit if it is taking up purely the user's hard drive space.

Even if there is no size limit in offline editor, it can't be a solution.
Because it is not applicable to "Imagine, Program, Share".

This is the project I concern about. https://scratch.mit.edu/projects/161762297/

I think this can be an instance of “Wide Walls”.
If you look at this project, you must recognize the quality and quantity of it, and the reason why I need extending the limit.

Unfortunately, this project size is almost 50MB.
Due to the size limit, I can't continue extending this project any more.

You could always provide your own download if you want to share it, just make a project to link to it and tell people about it.

In the FAQ it says: “New operators that make it easier to work with text (strings)”.

I can only see the contains operator. Will there be e.g. a substr/substring/slice operator or other string operators?

Greenduck54 wrote:

You could always provide your own download if you want to share it, just make a project to link to it and tell people about it.

According to my understanding,
to share projects outside of Scratch,
in that way, we lose the benefit of Scratch community function (comment, favorite, or statistics value, and so on).

In addition, I don't know if cloud variables work correctly.

inoking wrote:

to share projects outside of Scratch,
in that way, we lose the benefit of Scratch community function (comment, favorite, or statistics value, and so on).

No, you won't. Indeed they are suggesting that you provide the link to your downloadable project via a Scratch project, so people can comment, favorite, etc your “link project”.

inoking wrote:

In addition, I don't know if cloud variables work correctly.

Yes, you are right. They won't work.

s_federici wrote:

No, you won't. Indeed they are suggesting that you provide the link to your downloadable project via a Scratch project, so people can comment, favorite, etc your “link project”.
…
Yes, you are right. They won't work.

Indeed it is certainly a possible workaround.
It may be the last resort (if I continue providing it as a Scratch project).

However, cloud variables don't work,
it is the critical defect of this method.

I'm happy that Scratch 3.0 uses SVG for the blocks, but why did they use Canvas for the stage? As someone who has discovered the annoying performance issues of Canvas from making an editor of my own (not one like scratch), it would have made so much more sense to use SVG there as well. I do understand that the stage background works better with a canvas since it needs to be drawn on by pen, but the rest of the sprites and the performance would benefit from being displayed with SVG. The sprites would then be properly scaled up to a higher resolution, and the performance would benefit from not having to constantly redraw the Canvas every frame. I know that it is redrawing the Canvas every frame by using the performance tab of Chrome's DevTools, which also makes the device that Scratch is running on do more processing. SVG lets the browser automatically update it, so only actual edits trigger a new frame. SVG also supports actual click detection, so there doesn't have to be much processing to tell if a sprite was clicked. I do know from personal experience that converting an editor from Canvas to SVG is a big switch, so this is not something that needs to be done with the original release of 3.0. However, I do think that it would be a smart move to eventually use SVG instead of Canvas.

By the way, if anyone would like to check out the editor that I made, it is a Logic Gate Simulator.

ACE009 wrote:

However, I do think that it would be a smart move to eventually use SVG instead of Canvas

Nice simulator.
I don't know much of javascript (except for slightly modifying things made by others). What do you mean by using SVG instead of canvas? How do you manage graphics and animation by SVG in javascript?

s_federici wrote:

ACE009 wrote:

However, I do think that it would be a smart move to eventually use SVG instead of Canvas

Nice simulator.
I don't know much of javascript (except for slightly modifying things made by others). What do you mean by using SVG instead of canvas? How do you manage graphics and animation by SVG in javascript?

SVG and Canvas are two new HTML5 display elements. (Inline) SVG can be edited by JavaScript similarly to the rest of the DOM (the XML layout). Canvas has several different methods for drawing on it, but it does not store any information other than what it currently needs to display in pixels. The pixel part prevents it from being scaled up and keeping at a good resolution. If you would like any more information, W3Schools is a good place to look.

ACE009 wrote:

s_federici wrote:

ACE009 wrote:

However, I do think that it would be a smart move to eventually use SVG instead of Canvas

Nice simulator.
I don't know much of javascript (except for slightly modifying things made by others). What do you mean by using SVG instead of canvas? How do you manage graphics and animation by SVG in javascript?

SVG and Canvas are two new HTML5 display elements. (Inline) SVG can be edited by JavaScript similarly to the rest of the DOM (the XML layout). Canvas has several different methods for drawing on it, but it does not store any information other than what it currently needs to display in pixels. The pixel part prevents it from being scaled up and keeping at a good resolution. If you would like any more information, W3Schools is a good place to look.

Yes! W3Schools is what I use too! That's actually where I learned JavaScript.

ACE009 wrote:

I'm happy that Scratch 3.0 uses SVG for the blocks, but why did they use Canvas for the stage?

The first thing that comes to mind is graphic effects. I don't think there's a good way to do whirl or pixelate effects in SVG. Also pen as you pointed out.

The entire editor is looking quite a lot bluer now! (In develop, anyhow.)

At first I wasn't sure about my thoughts on this, but I think I like it – it sort of makes the white elements stand out more. For example, in the extension library, I find the items look more like “cards”, which is probably what they're designed as. Same deal with the sprite/costume/backdrop/sound icons.

The tabs were also tweaked, and I think the whole editor feels a bit more “tabby” now – because of both the tab redesign and the new background color (which makes the script area and costume/sound editor) stand out a bit more.

STILL no bitmap?
Not even at develop

_nix wrote:

The entire editor is looking quite a lot bluer now! (In develop, anyhow.)

At first I wasn't sure about my thoughts on this, but I think I like it – it sort of makes the white elements stand out more. For example, in the extension library, I find the items look more like “cards”, which is probably what they're designed as. Same deal with the sprite/costume/backdrop/sound icons.

The tabs were also tweaked, and I think the whole editor feels a bit more “tabby” now – because of both the tab redesign and the new background color (which makes the script area and costume/sound editor) stand out a bit more.

I'm also happy about this change, since now the contrast between the UI elements is a lot nicer (and because of the tabs) (I still don't really think the UI elements should be quite as fat and chunky as they are now, though.)

ACE009 wrote:

I'm happy that Scratch 3.0 uses SVG for the blocks, but why did they use Canvas for the stage?

While we do use a canvas element for the stage, the actual rendering itself is all done in WebGL. We went that route for a number of reasons including performance, handling of graphic effects (via shaders), and our need for a technology that could handling “touching color” performantly. While we also love the simplicity of SVG, in our evaluation we found that it wasn't a viable option.

MrMeowington wrote:

STILL no bitmap?
Not even at develop

We are working on it!

Greenduck54 wrote:

So, when an offline editor comes for 3.0, will it have no size limit? Because it should not have a size limit if it is taking up purely the user's hard drive space.

We haven't started on the offline editor yet, but that sounds correct to me.