Hello everyone!
I have a game I'm making. I just came from Scratch and am not all that accustomed to 
yet, but I know there are some ways to make it faster/more stable with the FPS. I also assume that when I port it using Snapp!, it will most likely be faster.
Edit: Forgot link: https://snap.berkeley.edu/project?user=snap0maker0&project=Grey%20Raynbou%20%231
Exactly the same as in Scratch: just use turbo mode (shift-click the flag).
Try turbo mode. It's just as slow. That's not what I'm asking.
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.
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")
.
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).
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.