Frame Manipulation Extension

reallysoftuser

Rewind is a feature found in many modern emulators. It continuously stores your game’s state in RAM. This way, it creates the equivalent of a recording of the X past seconds.

I think this feature would be useful for creating checkpoints in games, but I think this feature should be disabled for heavy/big projects, as it could cause issues in those. Also, the extension could only go back in time for a certain amount of frames.

⏺ save current state to slot [50 v] :: events // 1-50 
⏺ load restore point slot [1 v] :: :: events
⏸ pause :: events
▶ resume :: events
⏯ pause/play toggle :: events
◀ go back () frames :: events
⏪ rewind () frames for () seconds :: events
⏮ start rewind :: events
⏹️ stop playback :: events
go forward 1 frame :: events // when paused
override [sprite1 v] :: events // sprite won't be affected by rewind or pause
stop override [sprite2 v] :: events
when restore point slot [39 v] loaded :: events hat
when restore point slot [any v] loaded :: events hat

Last edited by reallysoftuser (May 3, 2022 15:40:12)

Geotale

“Many modern emulators” for incredibly old hardware lol
Doing this would make essentially any computer die when running, say, Chirpy Reverie, as you mentioned. “Large projects” isn't well-defined, but at the very least, this could very easily crash the webpage when the user doesn't intend to.
Adding to this, think about how many frames you'd need to save – A rewind that only lasts 1.67 seconds (50 frames) isn't very appealing, is it?
Of course, that will just add to the ginormous amount of memory and processing this would take, and for what?
Everything you mention here can be done far cheaper, and far better (i.e. you can add special effects to it easily) if you implement it yourself. As this clearly isn't meant for New Scratchers, and because it can't be implemented in large projects which will be able to use it best due to the massive overhead, I don't really see the point.

reallysoftuser

Geotale wrote:
Adding to this, think about how many frames you'd need to save – A rewind that only lasts 1.67 seconds (50 frames) isn't very appealing, is it?

I said you could only save 50 restore points, not fifty frames.

Also, I'd imagine smaller Scratch projects are about as complex as older games.

Geotale

reallysoftuser wrote:
Geotale wrote:
Adding to this, think about how many frames you'd need to save – A rewind that only lasts 1.67 seconds (50 frames) isn't very appealing, is it?
I said you could only save 50 restore points, not fifty frames.

Also, I'd imagine smaller Scratch projects are about as complex as older games.

Yes, I was using 50 frames as an example (after I actually did have confusion on this), though I could have made it more clear.

The issue is – “Smaller Scratch games” aren't going to be using this I wouldn't imagine. Combine multiples images with the already large amount of data it has to save for variables and every single setting, and you're up for a huge amount of space for anything that would use this, especially if you're going to allow for more than 50 frames of rewind.

k0d3rrr

Bumped, second paged.
(I now understand that!

)

Heccit

reallysoftuser wrote:
I think this feature would be useful for creating checkpoints in games, but I think this feature should be disabled for big projects, as it could cause issues in those.

What exactly qualifies as a “big” project?

reallysoftuser

Heccit wrote:
reallysoftuser wrote:
I think this feature would be useful for creating checkpoints in games, but I think this feature should be disabled for big projects, as it could cause issues in those.
What exactly qualifies as a “big” project?

Large in file size, or the program could detect when the project is using more performance than usual, and could temporarily disable the blocks then.

IndexErrorException

Major support. This could make scratch more like processing. Allowing users to make actual images and videos from scratch. Just next thing would be a custom size view port.

k0d3rrr

Would these also be blocks? Or are they too complicated for this extension?

▶ when restore point [1-50 v] resumed:: events hat

|| when restore point [1-50 v] paused:: events hat

■ when restore point [1-50 v] stopped:: events hat

RL1123

How would this work with framerate drops?

reallysoftuser

RL1123 wrote:
How would this work with framerate drops?

I don't think it would be that big of an issue, but I've stated in an earlier post that this extension would be disabled for performance heavy scratch projects.

Last edited by reallysoftuser (March 27, 2022 03:26:36)

RL1123

reallysoftuser wrote:
RL1123 wrote:
How would this work with framerate drops?
I don't think it would be that big of an issue, but I've stated in an earlier post that this extension would be disabled for performance heavy scratch projects.

File size doesn't directly influence how laggy a project can be. Paper Minecraft by griffpatch has a file size of 3.7MB and isn't laggy, but a script of 10 blocks can easily crash a project.

reallysoftuser

File size and performance would have 2 separate detectors. If Scratch detects the project is heavier than usual through performance, the blocks would be temporarily, and in the event scratch loads a big project, it will disable the blocks until a lighter project is loaded.

Last edited by reallysoftuser (March 27, 2022 03:53:06)

reallysoftuser

Bumped, second paged

reallysoftuser

reallysoftuser wrote:
Bumped, second paged

reallysoftuser

Second paged, bumped.

Crow_Boy08

BIG SUPPORT
i think these two blocks are very useful for pause screens

⏸ pause :: events
▶ resume :: events

reallysoftuser

2nd pg, bump

reallysoftuser

Bumped

reallysoftuser

reallysoftuser, on another good suggestion wrote:
Brought my topic back up to the first page, as it has reached the second.
Bumped.

Discuss Scratch