I was working on a platforming game but when I tested it in project page and embed page it ran very slowly and inconsistantly, but it was fine in the editor.
This might be a bug idk.
What a coincidence, I was just looking at your profile.
Personally, I don't know. I have a few projects that are fine in editor, but when ran in full screen or project page it becomes nearly unusable.
It works fine for me its fun too.
Update:
I just tried it on safari on iOS and it worked fine
When it didn’t work I was running it on chrome on windows
So it might be a chrome thing?
Interesting. When I run the project, I seem to have similar problems as well. (And am also using a Windows laptop on the Chrome browser), so perhaps you are correct.
I've looked a little closer at the lag, it appears that whenever the player is on screen, it is terribly slow, but when the player is offscreen, it runs at Snap!'s normal 60 FPS. Maybe there's something with the way the player is rendered that causes a lot of lag? Sprites are usually not rendered while offscreen, so it's likely that could be the cause of the problem.
I did test with a project that only had the fps counter and there was no slowdown, so there is definitely some specific thing that is slowing down
If anything it runs faster outside the editor for me.
After looking through the code a bit, I can't identify anything for sure as the culprit of the lag, but there are a couple things I notice that could be the source.
-
General usage of sprite-specific blocks:
For some reason, sprite-specific custom blocks can cause a bit of lag, as when Snap! tries to access one, it goes through every single custom block, which can add up, especially with more custom blocks.
Solution: Remove the sprite specific custom blocks (which could require a complete rewrite of the program and is probably not the best choice) or change them to global blocks, which are faster, and would be much easier to do. -
(Probably the source of most of the lag?) Repeated calling of blocks:
More likely the cause of the lag is the repeated calling and asking of sprite-local blocks. Every single frame, the program calls the (_ of _) block many times, which is entirely unnecessary for most of the usages. For example, all of the sprite-specific blocks are accessed every frame, even though they aren't going to change. Instead, just make a few script variables at the start, set the values to those sprite-specific blocks, and re-use them when you need it, rather than calling it again even though it hasn't changed and will never change. -
Reduce the overall number of custom blocks:
Like I said before, custom blocks can be a little annoying sometimes, so usually the less of them you have, the better, especially if they're being called all the time, like in your program. An easy fix to this is to group some custom blocks together, or delete some entirely: For example, you have a custom block for "touching wall" that is entirely unnecessary, as you could just use the normal touching block and set it to wall. Or, for grouping them, you have a couple custom blocks for player movement and collision. You might be able to group those together into only one custom block, called "player movement" or something. -
Multiple sprites that barely do anything:
Currently, you have 10 sprites in the project, but only one actually really does anything. Instead of using multiple sprites, which can cause lag, I would suggest either deleting some that don't do anything (like the random turtle sprite, or the fps sprite as its job can be taken over by game loop because it wasn't doing any movement anyway), or turning the functionality into clones. For the head, arms, and legs of the player, you could have a global list called body, and store 5 clones in it, each in a different location and anchored to the player, like it was with the sprites. By having them in lists, it could allow for easy access to them from the main sprite or other clones. The walls probably don't cause much lag, as they literally don't do anything, and the player could also be a clone, or it could be its own independent sprite, running its own code and not just being commanded by the game loop sprite.
Although, do take everything I say with a grain of salt, as I could be horribly wrong about something. But for now, I suggest trying to modify one of those and see if it helps.
Another update:
I just tested it on windows chrome again, and it was still slow, but when I minimized and unminimized the window it went to full speed
What on earth is going on
For me, Snap! seems to run faster in the editor, with fullscreen turned off. It runs even faster if I shrink the stage.
Firefox on Arch (btw)
In the past I have found some projects to only work properly in editor non fullscreen
This issue has been much stranger though