Remix of Jens' hourglass + a mistake

I've seen Jens' simulation of hourglass project somewhere. I liked it very much.

Sadly, it seems it has been unpublished since then.

Another Jens' project, 'mosaic', sharing the same core idea - preventing clones from overlapping - has luckily not been unpublished.

I've added to it the gravitation and bouncing off the walls - making it a kind of the original Jens' hourglass, I guess.

Every 35 seconds, see the counting down in the bottom left corner, clones start falling down again from above the 'hourglass'.

By pressing spacebar every so often, you can freeze the time (like in some kids' cartoons Santa freezes the time).

Even when the time is frozen, each clone ('sand' in hourglass) keeps slightly 'vibrating' (horizontally) in the air (i.e. by moving randomly for minimum -1 and maximum 1, with every 0.5 available in between) .

Any other idea - math people, I am looking at you :~) - how to get every 0.5 from the (-1, 1) interval; or is this the only way?


nice, I love your remix!!
(my project is still around, tho: Snap! Build Your Own Blocks)

Thank you, Jens, for replying and pointing out that your hourglass project actually has been public all the time. Idk why I haven't seen it (and thought it's been unpublished).

The more I think about it, the more it seems to me that I made a mistake by adding "move away from the 'walls'" portion of the script (in the "for each item" block) to the custom block.

I am beginning to see that it is doing the opposite of what was my intention.

My intention for the clones was to point towards the closest pixel of the 'walls' (but this is not what the "point to" block does) and then move in the opposite direction.

I forgot that the "point to" block, instead, points towards the center of the sprite, which I don't want, at least not in the case of 'walls' sprite (because it's center is in fact outside of the costume's pixels).

Hmm we do know where the closest point is, for the sake of the "ray length to" block. Perhaps that block should also have an option for the angle to the nearest point ("ray direction to"?).

Thank you, Brian, for suggesting it.

If it would not be too much work, can Santa - oops Jens (and the rest of Snap! dev team) - bring it as the season's gift to the community, hopefully it is not something only me would like to have, anyway...

Are you sure? I'm afraid "ray length" is the length of the "clear path" towards the object.
To solve the OP problem something like radar mode can be used - constantly rotating/sweeping sprite to find the direction of the smallest "ray length".

Oh foo, you're right, I don't know what I was thinking. Sorry!

Thanks, dardoro, you are right, that's what we need.

If the 'radar' part of code could be done 'stealthily' (sorry, I couldn't resist), i.e. by making it a fast primitive; and, if it would really be fast, it could still be called "ray direction to"?

Would you be willing to test the speed of such a custom block made by you, of course, because you are a true coding ninja, while I have no idea how to do it in javascript or any other professional language. Please.

No, that would be confusing. "Ray length" uses the sprite's current direction. It would have to be called "shortest direction to" or something. (Really it should be "direction of shortest distance to" but that's too much of a mouthful for a menu item.)

What about shortening the name to "closest direction to _"?

Sure, whatever. Not happening right away anyway.

I just now read this topic. I have a block here: Snap! 7 - rc3 - Build Your Own Blocks (Just made it. It's simpler to make than I thought.)

There is a Dist2Edge script pic block.
Even in half, not that spectacular as you expected :wink:
Rather on a slow side so more suitable for slope detection than multi-sprite
Test project

I made the block in the same project (Plus several bug fixes)


I am apologizing for not replying earlier, dardoro and joecooldoo.

In the past week I was not (psychologically) able to write anything because (a week ago) my father has been accepted into ICU because of ischemic left-side brain stroke and has been saved only thanks to fast response and IC staff. (Both emotion wise and otherwise a lot to process.)

I wish him a quick recovery.

tnx, Dariusz; hopefully he will recover as much as possible.

Same here, hope he recovers fast. :slight_smile:

tnx, joecooldoo.