Scratch-gui: 60 FPS Support?

[apple502j]

60fps support is often suggested: see this or this topic.

Scratch VM already supports 60FPS - We just need to disable "compatibility mode" which is set at https://github.com/LLK/scratch-gui/blob/develop/src/lib/vm-manager-hoc.jsx#L34

We should make it optional if it gets implemented, though.

[BoomerScratch]

I agree.
It would be nice if you can turn it on by ctrl-clicking the green flag, and also an option in the edit menu.

[apple502j]

note: ctrl-click is mute on 2.0

[BoomerScratch]

note: ctrl-click is turbo mode on 2.0

Is that really a problem? In 3.0, ctrl-clicking the flag does nothing. In 3.0, it's shift-clicking.

[Explosion-Scratch]

Support; this sounds cool but as Boomer001 said, cntrl clicking might work.

[apple502j]

@BoomerScratch I made a silly mistake :P it was mute

[redstone-scratch]

@BoomerScratch Support for that too.

[griffpatch]

60 FPS couldn't be an option enabled by the user of the project, it would
need to be a decision made by the project creator - Just in the same way
that playing a game in turbo mode makes most games unplayable, so would
doubling the framerate to 60fps from the standard 30fps. We would either
need new settings available perhaps on the stage gui (replacing the x, y
and rotation gui controls) or new scratch blocks to enable it... That could
be done in a scratch extension I'm guessing? I'd love that.

Scratch Pro Extension:

• Set Project FPS to [30 / 60 / Turbo]
• Set Project Aspect Ratio [4:3 / 16:9]
• Set Clone Limit [300 / 1000]
• Set Sprite Fencing [On / Off] -- Allow sprites off screen and to shrink
  smaller or grow larger than currently allowed
• Set Sprite Precision [Pixel / Sub-pixel] -- Allows sprites to be
  positioned at sub pixel boundaries... this may not be possible, but would
  be excellent for many games

Couple of extra nice to have :)

• Enable Sprite Sensing [On / Off] -- Allows us to remove a sprite / clone
  from being included in any sensing block detection
• Set Sprite Width [-200 ... 200] % -- Allows us to flip and stretch a
  sprite, could be partnered with a Set Sprite Height block, but not
  necessary.

While we are at it...
Touch Control Extension:
But how would it work! A block to enable a joystick type or add buttons?
A hat block like when sprite cloned for multi touch that when added to a
sprite that sprite is actually cloned by a touch and is positioned under
the finger and has another hat for when the finger is released... and
perhaps the clone is deleted when that script ends?
A new sensing block, that is multi touch aware so more
than one position on the screen can trigger them?

Sorry for sticking all this here lol... got carried away :)

Griffpatch

On Wed, 3 Jun 2020 at 22:22, RedstoneScratch [e-mail]
wrote:

@BoomerScratch https://github.com/BoomerScratch Support for that too.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LLK/scratch-gui/issues/5780#issuecomment-638468968,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTM3PTUZEGRSGL7ELYP73DRU25IJANCNFSM4NEVKJ7A
.

[apple502j]

Actually, turbo mode is not FPS - turbo mode increases "blocks run per tick/frame" by not waiting a tick when redraw is requested (am i right?). This is why it does not make sense to put it in a single block.

Project aspect ratio would be hard to change because a lot of things are relying on it, but if there is a way to manage it, it would be nice!

Increasing clone limit is rejected so I don't think it will come. Disabling sprite fencing would be cool, but may have a side effect on renderer, and so is Sub-pixel Sprite Precision.

Enable Sprite Sensing can be easily implemented because it's all VM matter. Set Sprite Width? hmm, probably.

However, I am not sure if making them blocks would be a good idea. Imagine "forever set project aspect ratio 4:3 set project aspect ratio 16:9" - that could be a bomb for low-performance computers. I'm not sure if extensions can/should occupy spaces that are allocated to a vanilla feature (like sprite pane control) - it would be better if it's an option in Edit menu. and project.json can probably store those as "default value" so that they can use the project at 60FPS by default!

[Explosion-Scratch]

@griffpatch Wow! All of those sound like cool ideas, I personally have no
experience in actual coding (like not with scratch) but how long do you
think it would take to code these into a fork of scratch? Would it be
possible for some AT'ers to do?
>
>

[griffpatch]

>

Actually, turbo mode is not FPS - turbo mode increases "blocks run per
tick/frame" by not waiting a tick when redraw is requested (am i right?).
This is why it does not make sense to put it in a single block.

Turbo just means there is no limit on the FPS, this is indeed achieved by
simply not waiting for screen refreshes it's true.

Project aspect ratio would be hard to change because a lot of things are
relying on it, but if there is a way to manage it, it would be nice!

Id suggest that when not fullscreen that it introduces bars at the top and
bottom, but when fullscreen it then fits the screen (no bars at left and
right)

Increasing clone limit is rejected
https://scratch.mit.edu/discuss/topic/11102/?page=1#post-375856 so I
don't think it will come. Disabling sprite fencing would be cool, but may
have a side effect on renderer, and so is Sub-pixel Sprite Precision.

Rejected verbatim, but perhaps now if it was setable in the project? So by
default it is still 300...

Enable Sprite Sensing can be easily implemented because it's all VM
matter. Set Sprite Width? hmm, probably.

I made a test PR for a stretch effect which worked great - it's already
implemented in the VM and renderer, it's just not settable because the set
size does both the width and height at the same time rather than
independently

However, I am not sure if making them blocks would be a good idea. Imagine
"forever set project aspect ratio 4:3 set project aspect ratio 16:9" - that
could be a bomb for low-performance computers. I'm not sure if extensions
can/should occupy spaces that are allocated to a vanilla feature (like
sprite pane control) - it would be better if it's an option in Edit menu.
and project.json can probably store those as "default value" so that they
can use the project at 60FPS by default!

I agree - I did originally want these options to be on a project settings
page, but that requires GUI changes and thought... whereas having things as
an extension and blocks allows many more options to be granted without the
need for any of that... So I thought it was a cool idea to suggest.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/LLK/scratch-gui/issues/5780#issuecomment-638743527,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTM3PR3VMTTEUPC3RRKMETRU5UR7ANCNFSM4NEVKJ7A
.

[apple502j]

Turbo just means there is no limit on the FPS

Hm, maybe you're true, though I still think "blocks run per Sequencer.stepThreads" != "interval between Runtime._step"

Id suggest that when not fullscreen that it introduces bars at the top and
bottom, but when fullscreen it then fits the screen (no bars at left and
right)

Is it any different from making such backdrops? Do sprites still bounce at the "border"? Can we place a stage monitor there? What happens to backdrops?

[apple502j]

TIL calling setCompatibilityMode while running VM breaks scratch-blocks

[apple502j]

@griffpatch see https://github.com/apple502j/scratch-vm/tree/pro-extension for some of the impl

[griffpatch]

On Thu, 4 Jun 2020 at 15:32, apple502j [e-mail] wrote:

Turbo just means there is no limit on the FPS

Hm, maybe you're true, though I still think "blocks run per
Sequencer.stepThreads" != "interval between Runtime._step"

You are right that under the hood in the VM they are different, but to the
scratch user it would make sense.

Id suggest that when not fullscreen that it introduces bars at the top and
bottom, but when fullscreen it then fits the screen (no bars at left and
right)

Is it any different from making such backdrops? Do sprites still bounce at
the "border"? Can we place a stage monitor there? What happens to backdrops?

Yes different, screen resolution would be 640x360 I'd guess. When
fullscreen it would fit the monitor without white sidebars, but when in
project mode it would allow more space below (assuming width is fixed in
the layout)
Stage monitors and list monitors are a problem - for these we either need
to fence them, or we could move them with their x positions scaled? but
it's far from perfect. As long as the aspect was saved with the project it
wouldn't be such an issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LLK/scratch-gui/issues/5780#issuecomment-638886973,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTM3PXPB4CRNMFYHYU2CCLRU6V6XANCNFSM4NEVKJ7A
.

[B294]

60 FPS couldn't be an option enabled by the user of the project, it would need to be a decision made by the project creator - Just in the same way that playing a game in turbo mode makes most games unplayable, so would doubling the framerate to 60fps from the standard 30fps. We would either need new settings available perhaps on the stage gui (replacing the x, y and rotation gui controls) or new scratch blocks to enable it...
…

Yes, maybe an extension perhaps? I think if they would have to use new blocks like that they should just add it in as an extension.

[SheepTester]

When compatibility mode is off, does it enforce 60 FPS? Or is it, like window.requestAnimationFrame, based on the screen refresh rate? If it's the latter, projects that rely on a constant framerate might run too fast for people using fancy monitors

[apple502j]

It should be always 60fps:
https://github.com/LLK/scratch-vm/blob/develop/src/engine/runtime.js#L2542

[peabrainiac]

60 FPS couldn't be an option enabled by the user of the project, it would need to be a decision made by the project creator - Just in the same way that playing a game in turbo mode makes most games unplayable, so would doubling the framerate to 60fps from the standard 30fps. We would either need new settings available perhaps on the stage gui (replacing the x, y and rotation gui controls) or new scratch blocks to enable it... That could be done in a scratch extension I'm guessing? I'd love that.

I think having these settings on the stage gui would be a little wierd considering that they affect the entire project and not just the stage... what about a settings tab next to code, costumes and sounds?

I feel like that would make a little more sense, at least if there are enough such settings that the tab wouldn't be almost completely empty.

[B294]

When compatibility mode is off, does it enforce 60 FPS? Or is it, like window.requestAnimationFrame, based on the screen refresh rate? If it's the latter, projects that rely on a constant framerate might run too fast for people using fancy monitors

We’d have to test forkphorus to see how it would work. It seems to run fine for me, but I don’t really use anything that runs really fast.

[redstone-scratch]

I could probably make a fork with all of this...

[jeffalo]

60 FPS couldn't be an option enabled by the user of the project, it would need to be a decision made by the project creator - Just in the same way that playing a game in turbo mode makes most games unplayable, so would doubling the framerate to 60fps from the standard 30fps. We would either need new settings available perhaps on the stage gui (replacing the x, y and rotation gui controls) or new scratch blocks to enable it... That could be done in a scratch extension I'm guessing? I'd love that.

I think having these settings on the stage gui would be a little wierd considering that they affect the entire project and not just the stage... what about a settings tab next to code, costumes and sounds?

I feel like that would make a little more sense, at least if there are enough such settings that the tab wouldn't be almost completely empty.

i really like this settings idea (maybe not there because it'd look like its a settings for the sprite) while we're at it, in settings there could be things like project title, maybe turbo mode enforcing/disallowing and stuff like that. i think this'd be very useful to have and also, when i was new to scratch i thought it was weird that there was no settings page and instead, the same page that others would view is the same place where you change things.

i mean also while we're at it, 16:9 support in settings would be nice 😜

[Explosion-Scratch]

@JeffaloBob Perhaps settings could have two sections. Project settings and user preferences. Here's what those could encompass:
-Project settings:
- Aspect ratio
- Allow sprites to move off of the stage completely.
- Disable/enable turbo mode at the start.
- User preferences:
- Dark mode
- Setting the clone limit. (Only for a single user. This would be set to 300 automatically and have to be reset to what the user wanted each time to change the clone limit. This is to prevent a user setting it to like 1000 on a loptop and then signing into mobile and the project crashing ther browser.)
- Block colors. (usefull for accessability and it's fun)
- Project info:
- Total blocks
-Total blocks in each category.
- Extensions
- Share and reshare dates

[Explosion-Scratch]

The list sort of broke. =/

[mxmou]

The list sort of broke. =/

@Explosion-Scratch Does the below work?

> - Project settings:
> - Aspect ratio
> - Allow sprites to move off of the stage completely.
> - Disable/enable turbo mode at the start.
> 
> * User preferences:
>   
>   * Dark mode
>   * Setting the clone limit. (Only for a single user. This would be set to 300 automatically and have to be reset to what the user wanted each time to change the clone limit. This is to prevent a user setting it to like 1000 on a loptop and then signing into mobile and the project crashing ther browser.)
>   * Block colors. (usefull for accessability and it's fun)
> * Project info:
>   
>   * Total blocks
>     - Total blocks in each category.
>   * Extensions
>   * Share and reshare dates

[Explosion-Scratch]

@mxmou It looks like the [code] tags in the scratch forums. It dosen't really matter though.

[mxmou]

@mxmou It looks like the [code] tags in the scratch forums. It dosen't really matter though.

I meant, if you copy this markdown code into your comment it should work.