Help with performance on line graphics code

Help with Snap! Snap! Editor
#1

My son and I are writing some graphics code, eventually for a game.

The code draws a parabolic path (100 line segments), based on the position of the mouse, which is truncated when it hits the ground (nine line segments). Before drawing each line segment of the parabola, we check whether it intersects each line segment of the ground, truncating the path at the ground and stopping if so. All of this happens in a warp.

It's quite slow. It's a lot speedier if the parabola is reduced to 15 (edit:25) line segments (set dt=.4), but doesn't look as good.

Admittedly, doing ~1000 intersection checks every refresh is a lot of work, but I'm not convinced Snap can't handle it.

I think we're following all of the advice in the FAQ, but we're far from experts. Is there any easily addressed coding issue that would help our performance? My son wants to speed things up and I'd rather avoid getting (more) into the weeds optimizing the code.

Thanks in advance.

#2

Alternately, is there any way to profile code (maybe by downloading the offline version?)

#3

Well, first of all, the project runs plenty fast for me!

But instead of doing all that math at each step, you could use one of the TOUCHING blocks to detect hitting the ground. The most straightforward thing would be TOUCHING COLOR [black], but since that's a little slower than the test for touching another sprite, maybe after drawing the background, you should have another sprite do
untitled script pic
and then the first sprite can TOUCHING (Sprite (2)) or whatever it's called.

#4

Thanks for your reply. These are great ideas; we'll try them. I should have said that it's quite slow, according to my son. I grew up in another decade and it did not seem slow to me.

#5

I just tested it out, and I've noticed that the smaller the arc is, the slower the project runs, and vice versa.

#6

I agree. I think it's the number of segments of the parabola it draws. If I move the mouse below the "cannon" (where it would be if we drew one), the refresh is quite snappy. If I move it above that point, it slows to maybe 2 refreshes per second.

Drawing the segments isn't the issue. There's a loose chunk of code in the sprite that draws a zig-zag of 100 line segments, starting at the origin and ending at the mouse cursor. If attached to WHEN GREEN FLAG CLICKED, it runs smoothly.

#7

The "sprite" clones are not deleted after leaving the stage. "Then I start as a clone" continues indefinitely.

On my computer, "draw bullet path" takes 200-500 ms to complete with ~30 segments drawn.

There is a "ray length" reporter.
You may first use pen trail as a costume.
untitled script pic (28)
Rotate the sprite towards end of new segment, and check
untitled script pic (29)

#8

Hello, I tried a new approach with 3 sprites.

I'm here if you have any questions...

Here's the project

#9

This is really snappy with the "repeat until" in a warp. On the other hand the way the parabola is drawn without the warp is kind of cool.

#10

Good catch on the clones!

We'll play with ray length; we haven't used it before.

#11

Thanks all! Making the ground a sprite costume and using the TOUCHING block worked for us. We haven't experimented with pen trails yet; We avoided paths that tunnel through the top of the mountain by increasing the resolution of the parabola.

We're new at this, and did not think to make a static copy of the code to post for this thread. Apologies for any confusion to later readers.

@loucheman Your solution was along the lines of what we did, but I could only mark one post as the solution.

#12

No problem !

#13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.