Nerdy Hopscotch Questions - Coding Megathread

Hmm… memory leaks? :thinking:
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.

3 Likes

someone ready to test that out?

3 Likes

Already have before, I pretty sure I did z index 99999999 before it womped!

1 Like

Welp now i know the best way to have intentional lag (not that i want it)

More fun frame rule stuff:

1 Like

I believe it stays around for a frame or so then it gets removed.

That would make sense but not by much.

They’re not strings. Currently in player 2.x there is no way to get a string with only digits. Characters between block no longer always returns a string

Yes the player definitely has memory leaks.

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.

6 Likes

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!)

Yes, that’s correct.

5 Likes

Where is the modding tool or project search on the web player?

1 Like

not public yet – it’s a browser extension

1 Like

Where is the browser extension. Or is it not out yet

1 Like

“Spider HS” still choosing a name

AE is also still working on it

pretty awesome (e)

3 Likes

is it more beneficial to increase the stage size when making an art pad? (1024x768 → 4096x3072)

or if i ask the question more generally…

if i have a modified stage size that is bigger than my original, will last touch xy be more precise compared to unmodified stage size?

2 Likes

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!

4 Likes

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:

  1. The person plays at a resolution such that Last Touch X and Y will be decimals
  2. 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.


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

5 Likes

ok, got it, thank you so much :+1: and nop dont worry, that was perfectly clear :)

3 Likes

For me Z index’ value is 0 around the 100000000.

It’s pretty annoying, I spent 30 minutes finding out why my object didn’t appear…

1 Like

@Awesome_E @Crosbyman64 and anybody else

is it more fps-consuming to code:

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

3 Likes

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

4 Likes

ok, thank you so so much!!!

e: interesting, my ipad lags less on the 2nd option :face_with_monocle:

1 Like

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

2 Likes