Expert Snappers who know how to make things faster?

It's the use of the warp blocks for the Touch Ground and Walk blocks. Removing the warp fixes the lag, but the character takes quite a while to rise out of the ground. At that point it's more of an issue with the ground detection. Alternatively, you use warp only when the character is clipped into the ground but the way the Touch Ground script is set up makes the placement of a warp less obvious.

Thanks. I'm going to have to experiment around...

It's in the else statement where we actually pull the player out of the ground. The lag seems to be in the Walk block. But not warping it leads to jittering if you move in the air or wall-jump. Warping it brings back the lag, so I'm just going to optimize it. I'm sure there's a declarative way or something to do it but I'm really bad at that. I can't read code that doesn't say what it does top-down. But I'll try. Thanks.

Nope, that's doesn't work (ha ha) at all (ha ha ha). Oh man this is confusing. Repeats seem to be really slow in Snap! as they seem to override inner warps so they update every tick (makes more sense than Scratch) the transition is hard. Can you please help me wrap (no pun intended) my head around what's wrong in the Touch Ground block that makes it like this?

It's strange, the Touch Ground code is similar to the code in this Griffpatch tutorial, I'm guessing you were loosely following that, but something different is happening here. I modified the code slightly: making it an exact replica of the Touch Ground block in the tutorial, wrapping that block in a warp, and then placing inside of the "if wall jump = 0" C-block, and the project runs somewhat faster, but the hitbox is in a constant state of falling if I do that.
Maybe refactoring the code could help, such as moving the controls section of the forever loop into its own custom block.

Yes I was following that tutorial exactly. But there was a reason I was using Snap! instead of Scratch -- there were simpler ways to do things! I should probably scrap the existing code and rebuild it.

I measured frame count and time of jump sequence. It took 25 iterations of the "hitbox" main loop to go up and down.
You can test this script to check the time. My system need 2 s to complete 30 such iterations. So the target framerate is 15 FPS and speed of objects and decelerations must be adjusted to get desired visual results.
In "Turbo" mode there are only a few emergency refreshes per second but loop speed is limited only by workload.

Grey Raynbou #1 script pic (1)

All right I spent hours break apart the loops and restructuring them and nothing seems to prevent the jittering without sacrificing speed. It might be the problem of loops overriding warp, which although makes sense, completes breaks efficiency. Any naturally declarative programmers who can see about converting this? Trying to decipher this just makes it less efficient.

Every "warp" steals 1 frame and slow loops down 2 times. Invoking "warp" this way doesn't interfere with the loop.

Broadcast_and_wait ("tick")

Grey Raynbou #1 script pic (2)

.
There is something strange about your project.
This script took 1 s to complete with the newly created Snap editor (running at 60 FPS). But with your project loaded (not running) works at half speed (30 FPS).
untitled script pic (20)

There is something strange about your project.
This script took 1 s to complete with the newly created Snap editor (running at 60 FPS). But with your project loaded (not running) works at half speed (30 FPS).

That's... weird. Very weird. I see if creating a new project and isolating the scripts seem to do anything. Anyway thanks for the tip.

Found it, there is a hidden preference (with ) "Prefer smooth animation".

So that's what's slowing it down?

All of this this.
Base frame rate with smooth animations 30 FPS. Without "smooth" 60 FPS.
Loop with warp - FPS/2.

Alright. I'll get to work. But maybe in an hour, I'm working on bezier curves right now and I wanna stay focused.

Keep working...

BTW:
"Stage" sprite full stage graphic effect slows down when in fullscreen..

Although I have a cheaty solution, the use of JavaScript typically improves performance when compared to a large number of blocks. Although I can't talk about it too much without this turning into an Advanced Topic, if you know JavaScript, it can boost performance quite a bit, at least in the current version of Snap!

Hmm. Javascript-intensive project in a platformer? I'm not so sure... I was trying to avoid this, I guess I just didn't want to get into all that. I'm trying different things and at this point it seems like the only solution, 'cause only more mechanics are going to be added.

Well, from what I've heard, you've taken a look at my rendering engine. If you look inside of the blocks, most of the source code is either entirely or mostly in JavaScript. This does come to a cost (like when you need to wait for yielding (waits before it finishes) block to finish), but you can compare this to when I first started trying to make one. It was so laggy, even when I was drawing at fractions of the resolution (with no lights or even shading!)

Advanced topic examples:
https://forum.snap.berkeley.edu/t/executing-rings-with-js/1687/22

And if you don't believe them:
https://forum.snap.berkeley.edu/t/draw-pixels-instead-of-dots/1684/3

All right, I had more time today and converted the Touch Ground block into JS but it's slower than warping it! Does the entire project have to be converted before any changes take effect or am I doing something wrong?

Usually, for the biggest performance benefits, you must convert large chunks of blocks into JavaScript. Typically anything object related (like creating things like lists and manipulating them), things that are very complex (made of several blocks and very complicated), and things that are done iteratively (for/foreach loops) are far faster in JavaScript. I think iterations are likely the biggest impact on your project, so what I said is ordered from least impactful to most. Converting like one or two random blocks that are frequently used wont have as much of an impact as converting some logic that manages projectiles iteratively. I had one example where I computed distance between some point functions in Snap! for every time I needed to continue ray steps. I converted it into JavaScript and the performance was so much better.

This optimization does involve abstracting away from using Snap! blocks though, so as long as the interface of using the blocks makes sense, the inside typically doesn't need to be perfect and clean, although it is appreciated if the code is well commented and written.