Yo. An idea on highly complex projects in which the .json of the code exceeds the .json limit.

As many may know there are two size limiters in Scratch–a .json limit, and an individual asset limit. There is no limit to the actual size of the project.

Say you are programming a highly complex system, but suddenly POW you've used up the 5mb .json file limit.
(If you're reading this because your .json is maxed, make sure you aren't saving any humongous lists.)

Well, you've used the JSON limit, but what about the asset limit?
BOOM! Pixel-based programming. Just program everything in turbowarp, ENCODE the programming to SPECIFIC COLOR VALUES on a COSTUME, and then create a decoder which reads each pixel's color value and determines an operation from that. This way you can vastly exceed the theoretical code limit without exceeding the project .json limit. Of course, the hexadecimal decoder to code would be a heck of a lot of .json but i can bet it won't be 5mb worth.

This system could also be used with very very large lists, such as 3D map lists, or even LLM AI, as lists take up the .json and get in the way of saving.

This could be very useful for a 3D engine.

[Click here] nice idea on it

StarWalker600 wrote:

CRAZYTVSTU wrote:

StarWalker600 wrote:

CRAZYTVSTU wrote:

Could be possible with this

https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/805201/

Looks promising, but it would be slow, not to mention scratch is already slow.
But… it can work
We can save pixel data in base 16 million ig cuz there are 16 million possible colors (even more if u take transparency into account). We save it to costume as u said, then we read it using the color detector thing griffpatch made then we convert the base 16 million into smth more sensible like hexadecimal or decimal. We can then use it to essentially write assembly program

But this relies on the fact that there are no asset limit

What ill do is ill make a project to test this. Ill obvs not go for base 16 million cuz thats kinda crazy uk

Yeah exactly. Also there's gotta be a point to not optimize the save file. Like, the less optimized the save file is, the less work goes into encoding/decoding it and thus a smaller .json and a larger .png or whatever file type Scratch defaults to. In other words, we would basically have to make each block, each operator, each boolean etc, its own pixel, and how they connect would either be communicated in extra pixels or in pixel order

Edit: Also, theres 480x360 pixels on each costume i BELIEVE (haven't double checked that) which means that each costume can contain 172,800 thingies. Thingies, like, bytes, or whatever the equivalent is here. I suggest we call them Pixelbytes

what im doing is making a virtual machine (tada the SVM scratch virtual machine). So we will hv to program in assembly cuz thats more simpler to compile into scratch blocks

EDIT1: We can then use the color values to determine which assembly instruction is written, along with its parameters. a different project can be used to make programs
EDIT2: Lets continue this conversation on ur topic as this is going off topic
EDIT3: Is this approach good or should I do some other way???

Not quite sure what you mean by programming in assembly, but from edit1 it sounds like a good approach lol

Also I can confirm there is no asset limit, at least on sound, i'm working on a 3xLP to release on Scratch and it has like 30+ sound files and 3 HD-uploaded pictures and it's saving fine

CRAZYTVSTU wrote:

StarWalker600 wrote:

CRAZYTVSTU wrote:

StarWalker600 wrote:

CRAZYTVSTU wrote:

Could be possible with this

https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/805201/

Looks promising, but it would be slow, not to mention scratch is already slow.
But… it can work
We can save pixel data in base 16 million ig cuz there are 16 million possible colors (even more if u take transparency into account). We save it to costume as u said, then we read it using the color detector thing griffpatch made then we convert the base 16 million into smth more sensible like hexadecimal or decimal. We can then use it to essentially write assembly program

But this relies on the fact that there are no asset limit

What ill do is ill make a project to test this. Ill obvs not go for base 16 million cuz thats kinda crazy uk

Yeah exactly. Also there's gotta be a point to not optimize the save file. Like, the less optimized the save file is, the less work goes into encoding/decoding it and thus a smaller .json and a larger .png or whatever file type Scratch defaults to. In other words, we would basically have to make each block, each operator, each boolean etc, its own pixel, and how they connect would either be communicated in extra pixels or in pixel order

Edit: Also, theres 480x360 pixels on each costume i BELIEVE (haven't double checked that) which means that each costume can contain 172,800 thingies. Thingies, like, bytes, or whatever the equivalent is here. I suggest we call them Pixelbytes

what im doing is making a virtual machine (tada the SVM scratch virtual machine). So we will hv to program in assembly cuz thats more simpler to compile into scratch blocks

EDIT1: We can then use the color values to determine which assembly instruction is written, along with its parameters. a different project can be used to make programs
EDIT2: Lets continue this conversation on ur topic as this is going off topic
EDIT3: Is this approach good or should I do some other way???

Not quite sure what you mean by programming in assembly, but from edit1 it sounds like a good approach lol

uk assembly language
U can read this

StarWalker600 wrote:

snip

uk assembly language
U can read this

Ohh, ok– that is probably a good approach, although there could be prompts used in assembly that don't have a corresponding function in Scratch and we'd have to custom program them

CRAZYTVSTU wrote:

StarWalker600 wrote:

snip

uk assembly language
U can read this

Ohh, ok– that is probably a good approach, although there could be prompts used in assembly that don't have a corresponding function in Scratch and we'd have to custom program them

Yeah. We can also use this opportunity to add our own instructions to make programming even more easier

This assembly language comes at a cost: well hv things like registers & stuff instead of variables & lists & c blocks are gonna be wierd especially loops

EDIT1: I got some progress check my profile page

Yo @CRAZYTVSTU Check my latest comment at the project we hv a problem we can only store ~16.4K instead of ~16.8M from my calculations

[Click here] & then scroll down to abusing color sensitivity

StarWalker600 wrote:

[Click here] & then scroll down to abusing color sensitivity

I think it's saying that's a workaround to detect all colors? not sure though