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.
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
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 ↩︎
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).