is there a way to repeat something instantly?

cooldude12547REBORN wrote:

is there a way to repeat something instantly?

put it in a “repeat 2” block. It'll be executed twice, one after the other.

If that isn't what you meant, explain more clearly.

i mean like it doesnt wait after executing, so it doesnt take long to detect the color

A custom block with no screen refresh is usually the fastest option but if it takes over 0.5 seconds (I believe) the advantage of no screen refresh is effectively lost. So possibly worth breaking it down so it doesn't do all colours at once for example, but does them in groups.

deck26 wrote:

A custom block with no screen refresh is usually the fastest option but if it takes over 0.5 seconds (I believe) the advantage of no screen refresh is effectively lost. So possibly worth breaking it down so it doesn't do all colours at once for example, but does them in groups.

what do you mean?

cooldude12547REBORN wrote:

deck26 wrote:

A custom block with no screen refresh is usually the fastest option but if it takes over 0.5 seconds (I believe) the advantage of no screen refresh is effectively lost. So possibly worth breaking it down so it doesn't do all colours at once for example, but does them in groups.

what do you mean?

I mean what I say. Which bit of it don't you understand?

deck26 wrote:

cooldude12547REBORN wrote:

deck26 wrote:

A custom block with no screen refresh is usually the fastest option but if it takes over 0.5 seconds (I believe) the advantage of no screen refresh is effectively lost. So possibly worth breaking it down so it doesn't do all colours at once for example, but does them in groups.

what do you mean?

I mean what I say. Which bit of it don't you understand?

nevermind. how long do u think it would be if i broke it down?

cooldude12547REBORN wrote:

deck26 wrote:

cooldude12547REBORN wrote:

deck26 wrote:

A custom block with no screen refresh is usually the fastest option but if it takes over 0.5 seconds (I believe) the advantage of no screen refresh is effectively lost. So possibly worth breaking it down so it doesn't do all colours at once for example, but does them in groups.

what do you mean?

I mean what I say. Which bit of it don't you understand?

nevermind. how long do u think it would be if i broke it down?

It'll probably still be slower than you'd like! I was really just pointing out that a custom block with no screen refresh isn't always faster.

If I was you I'd start with a much smaller subset of colours and get it working reasonably quickly if possible. Perhaps only a section of the screen as well. That'll give you some idea of how the time will build up as you expand it. If you use custom blocks try with and without the no screen refresh option selected.

ok

Currently I am working on a program that scans only part of the screen (360*270). It goes pixel by pixel. The screen is divided into 4 sections tasked with each scanning only 24300 pixels. When scanning the 360*270 mini canvas with one pixel reader it took 4 hours to complete half of the screen. When scanning the 360*270 mini canvas with 4 pixel readers it took 3.75 hours to complete half of the screen.

Honestly, there was not much of a difference between the two tests. This was because when one scanner hit a brighter/more saturated color, it would take more processing power away from the other 3 scanners causing them to lag. All of the scans used @DadOfMrLog 's scanner, turbo mode on, and custom blocks (with the run without screen refresh option on). I tried this in phosphorus.github.io (which does not have a limit on memory or processing power, unlike scratch does) and it broke.

So the real answer to your question is yes, there is a way to scan the whole screen and print it in pen so another person can see it. The problem: it would take too long to even refresh the screen in 3 hours even if you had a powerful computer.

> Oh yeah. The higher the brightness/saturation of a pixel the longer it takes to read and output. Considering this, you can put an overlay of a black screen with

set [ghost v] effect to (50)

and it should render a little faster.

i was only planning on doing a 100x100 area on the screen.

cooldude12547REBORN wrote:

i was only planning on doing a 100x100 area on the screen.

Oh okay so that would take about possibly 16 minutes per render.

one weird idea i had was to write a script (not on scratch, with java or something like that) that creates a json object representing all the colors and pixels and stuff like that. then i could make an sb2 file with the json. btw if the webcam is turned on in a certain sprite, is the thing showing it the same size of the sprite of the same size of the screen?

cooldude12547REBORN wrote:

one weird idea i had was to write a script (not on scratch, with java or something like that) that creates a json object representing all the colors and pixels and stuff like that. then i could make an sb2 file with the json. btw if the webcam is turned on in a certain sprite, is the thing showing it the same size of the sprite of the same size of the screen?

I tested that with my own webcam and found that the image sent to scratch by the webcam will always be the size of the screen. HOWEVER, I did find this project that quickly takes the image on the screen and can downscale it! Link: https://scratch.mit.edu/projects/66980580/

And two things I want to point out:
1. You said that you wanted the screen size to be 100x100. This will cause you to go though tons of pain as you would have to change the pixel ratio of each and every pixel. Instead look up “Downscaling Calculator” on Google (A good website: https://bneijt.nl/pr/resolution-scale-calculator/) and input the size of the scratch canvas (480x360). A size from 240x180 to 96x72 would be nice. The problem is that it still would take too long to render and FPS would be at the max of around .5 to 1 (theoretically) at a screen size of 16x12.
2. The project itself could be against the Scratch TOS as this is a way for people to communicate. You compared your project to Omegle. This takes the webcam feature (which may I say was not a good idea in the first place for the ST to make that a feature) and transmits the data to the Scratch servers. This is like on some level a chatroom. I am not saying to end development on this project. On the contrary, I am saying to find a way to monitor the data being sent or keep this project private.

This one is extremely fast

define colour
repeat until <touching color (colour) ?>
set [color v] to (pick random (0) to (100100100))
end

It takes approximately 0.01 ~ 0.1 secs to “guess” the colour the object is touching.
But i am not sure if it's working completely yet

when I receive [a problem v]
ask [help] and wait
if <[problem] = [solved]> then 
play sound [applause v]
else
repeat until <[i am satisfied] = [true]>
ask [help] and wait

end

It's very fast, and i use it to create something like a camera saver, that saves what the camera is looking at.
btw if you made the script, there's a weird bug in scratch that you first need to save it and reload it then, otherwise it somehow doen't work

when I receive [a problem v]
ask [help] and wait
if <[problem] = [solved]> then 
play sound [applause v]
else
repeat until <[i am satisfied] = [true]>
ask [help] and wait

end

cooldude12547REBORN wrote:

im making something that stored info from the webcam so that it can be stored with cloud data

ALERT! YOU CANNOT DO THIS! You cannot store pictures of other scratchers in the cloud. Otherwise, other people could “hack” the project and see pictures of other people! Please don't make a project like this - it's against community guidelines.

Don't worry ! This is an old post.

It was possible when cloud variable was big enough but now with only 2560 caracteres it's not possible anymore.