Hmm… memory leaks?
That does count as a memory leak right? lol
Hmm, actually do you think that’s related to the SVG engine? Maybe Set Object (changing the shape for example) has the same performance hit?
(I’m actually now wondering if new SVG text objects are instantiated every time behind the scenes, or if they just change text contents. I’m guessing i uses <svg>? I would hope that it’s the latter…)
I’ll definitely need to mess with projects in the browser console a lot more.
I’ve been working on a player mod to explore these sorts of things in the app more easily and to step through code one block at a time, which should make debugging code that is split across multiple rules easier.
If I recall correctly, whenever an object changes its z index the player sorts the objects at the start of the next frame. To do this, it makes a huge array that is the size of the highest z index set, which would take a lot of memory at higher z indices. Definitely try to keep z indexes low and change them infrequently for best performance.
So you make the player interface, I make the editor interface? Got it. Here’s my preview of what I’m working on (finally I can show it now that the web editor is released!)
woah it’s not worth it - the editor black screened and then the app crashed at 4096x3072, and it’s super laggy at 2048x1536. i guess im gonna stick with 1024x768. however tho, the last touch xy got more precise with bigger stage size!
In most cases, this doesn’t make a difference. Touch displays and mouse inputs are always whole numbers to the system (i.e. a 1920x1080 display will have touch/mouse x values of [0,1920) in whole numbers only), and Hopscotch’s Last Touch X and Y value’s are actually not rounded.
The only way changing the stage size would make a difference is if both of the following are true:
The person plays at a resolution such that Last Touch X and Y will be decimals
The person plays on a large enough screen such that they will see the difference in precision of object positions.
The larger stage size allows you to position objects more precisely[1]
lol that was confusing to write, hopefully less so to read. maybe a visual would help. but TLDR; modifying the stage size only affects object positioning precision and not touch position.
i.e. (0,198) on a 4096x3072 stage is (0,49.5) on a 1024x768 stage, meaning that if you play on a screen with a logical resolution of 4096x3072, a 1x1 square (for example) can only be rendered on every 4th pixel for the smaller stage, but can be rendered on every pixel for the larger stage ↩︎
Repeat forever:
Draw a trail color: // so Hopscotch constantly does pen up + pen down
Wait til Timestamp 7=7
End
End
or
Draw a trail color:
Repeat forever:
Set trail color to [] // so Hopscotch constantly updates these pen values
Set trail width to []
Wait til Timestamp 7=7
End
End
both seem to have my fps around ~51, and without timestamp block it drops to ~45
I just made a little lag test. All it does is do the same Draw A Trail based operations 1000 times per frame.
Both seem to be at the same FPS for me, and both do the same number of strokes per frame, but the second option might take a tiny bit more file space (though not by much once g-zipped)
Not only that, but the first option will allow you to end a line rather than have them all connected to each other at all times (No amount of Wait until Timestamp will fix that, you’ll need to add the Pen Down and Pen Up blocks for that).
If they’re not close enough to be the same, this would be my assumption – use the second unless you have a good reason to do the first. It shouldn’t be much different though