bharvey wrote:

_nix wrote:

Sounds like what you want could realistically be done, more or less, with a vector-based (ala SVG) notion of what is on the stage

That's a good thought, but I'm not sure, because of just the capabilities we're talking about: Can you do floodfill and touch sensing on a vector canvas? The algorithms typically look at individual pixels. I suppose there could be different algorithms for vector pictures…

I'd like to say there are formulas out there for checking if a line or curve intersects with an arbitrary shape (e.g. a sprite), but I'm not sure there is and I have no idea if they'd be at all performant. Maybe if everything were strictly comprised of rectangles and straight lines? (Which is actually relatively true, since pen lines are obviously lines and sprites can be made of “rectangle-ized” bitmaps.) Floodfill is not too complicated.. when you can make the assumption that every thing drawn with the pen is a closed polygon, but that's not a given

hjcpps: I don't plan to try to implement any of this but it's fun to discuss

hjcpps wrote:

As to aliasing: I noticed another thing that might catch kids. In your coordinate system, whole numbers are between the pixels. Makes sense. An imported costume automatically has the center set at the physical center. Makes perfect sense. For a 20x20 costume, the center is between pixels. But for a 19x19 costume, the center is on a pixel. When the sprite is at whole-number coordinates, the costume is aliased. I will fix this for me by padding my sprites to even dimensions with a transparent border using ImageMagick.

I can't reproduce this now. I must need more sleep.

hjcpps wrote:

Oops, I didn't mean to spark a revolution. Now I see why Jens hates these discussions.

All of us, Jens included, wants Snap! to be perfect. You at least provided something actionable, a specific project that works in edit mode but not in presentation mode. Jens gets frustrated with airy discussions that can't lead to a practical solution. And also with people who insist that their obscure problem is more important than everything else on the list.

I have no idea at this point whether a vector solution would work. What happens when you import a bitmap costume? But, you know, if someone like you or _nix wanted to do the research to see what would break if morphic used vector objects as sprites, that would be interesting. Make a fork of the repo and have fun. Just don't expect Jens to pull a PR that makes major changes; he'd want to write it himself, if anything.

But, don't feel bad about having started the conversation!

bharvey wrote:

What happens when you import a bitmap costume?

Apologies for me choosing to address a tiny question that doesn't actually matter in terms of getting stuff to work in high quality; but SVG allows embedding bitmaps. It's not really possible* to invent quality when there was none to start, so scaling these bitmaps as if they were bitmaps makes sense (i.e., if someone chooses to embed a low quality image, it's unreasonable to expect Snap! to be able to scale it without losing quality). If it was important for <touching> detection that the sprite was represented in vector, a vector outline could be automatically created when importing? *shrugs*

*I believe there are things that estimate what you meant and make curves out of them. Too much bother, though, imo.

bharvey wrote:

But, don't feel bad about having started the conversation!

I started nothing. I don't recall mentioning anything about super-duper resolutions, vector graphics, or major changes. I am a simple beginner who shares observations that are usually (1) a gap in my understanding, or occasionally (2) a minor bug that may be easily addressed. My personality is more actionable and practical, and my current state here is very humble.


Is there a way to “disable” a sprite? I would like to disable its receiving of events. By hiding a sprite, the mouse events are effectively disabled. What can be done about keyboard (and maybe even broadcast) events? My only idea is to create a global state variable. It would be checked first thing whenever an event is received.

Say a project has several screens. A menu screen may listen for various keys. Maybe a pause screen listens for ‘any key’ to resume. While playing the game, continuing to listen for these keys is useless overhead.

Or say I need to use a “when <predicate>” hat block, but only for short periods of time. Is there a way to turn off listening when it is not needed? My only idea here is to create my own polling loop to check the predicate, as well as checking whatever state makes this loop no longer needed.

Or say I have a bunch of sprites listening for broadcasts to do something. Maybe to each move left in their own way or to each play their note. If half of the sprites are not currently in use at any given time, how do I turn them off?

hjcpps wrote:

bharvey wrote:

But, don't feel bad about having started the conversation!

I started nothing. I don't recall mentioning anything about super-duper resolutions, vector graphics, or major changes. I am a simple beginner who shares observations that are usually (1) a gap in my understanding, or occasionally (2) a minor bug that may be easily addressed. My personality is more actionable and practical, and my current state here is very humble.

Ah but your “minor bug” turned out to be complicated to fix. And I think all this discussion of how ideally to do it is worthwhile, even if not immediately actionable. (I'm not Jens. )

Is there a way to “disable” a sprite? I would like to disable its receiving of events. By hiding a sprite, the mouse events are effectively disabled. What can be done about keyboard (and maybe even broadcast) events? My only idea is to create a global state variable. It would be checked first thing whenever an event is received.

Yeah, that's as good as anything. I agree that there should be a way to “turn off” a sprite. Hiding it, as you point out, does that halfway. Especially since we invented the generic WHEN block, which is really expensive, there should be a way to disable them more fine-grained than the stop button. On the list…

bharvey wrote:

On the list…

A list, great idea! I could have one key listener. Sprites that want to hear that key event could register a procedure to call. The key listener could keep a list of these event handlers. Disabled sprites could deregister. First class procedures used to create first class hat blocks.

I think I just reinvented the wheel. Sometimes I do have a tendency to make things too complex. Sigh…

hjcpps wrote:

First class procedures used to create first class hat blocks.

Awesome!

Soooooo, about that Snap community all its own….. it's been about a year now….. and it was being discussed a year ago that it was going to open Real Soon Now…… and then I was hearing “Maybe Over Christmas we'll do it” and so now it is very literally six months later, and it's still not here…..

Could you please stop trying to make the new Snap community Perfect and just release it in its current form, whatever it may be?

,

It is so annoying not having a central repository for people to easily share and view each other's Snap projects, as with Scratch.

It is so annoying to still see all Snap discussions all crammed together and still living in the basement apartment of another forum of an unrelated project, that can't be bothered to even Sticky the project thread so it is easy for people to find.

Dale_Mahalko wrote:

Soooooo, about that Snap community all its own….. it's been about a year now….. and it was being discussed a year ago that it was going to open Real Soon Now……

I'm sorry. Yes, we've missed more than one announced deadline for this project. But it really is getting closer now, because we have control over our back end now. That's not vaporware; it's running. After that, our first urgent priority has been to keep a few old versions of projects, to ameliorate the (rare) situations in which someone's project disappears. That is now written and will be up soon, in the next release. After that, we have a prototype of a sharing site, but it has to be integrated with our actual back end, rather than the fake one used in its development. That'll be this summer; we don't want major upheavals during the school year.

I probably should not tell you this.. but not all schools use the same scheduling. Some operate September to June, some operate year-round with about a month off between class sessions. You will never be able to make everyone happy.

Why does the “old Snap” cloud storage have to go away? Just leave it there and rename the URL for it, so that people can still find it and use it when the new thing has been released.

Then you can make the change to the new thing at any time, and merely put a pointer at the top of the page for new thing: “Looking for our previous online edition? Go here!”

And no one will be disrupted other than having to click through to the old version.

Dale_Mahalko wrote:

not all schools use the same scheduling.

You're right. I confess, we're thinking about US public schools, almost all of which are on a September-to-June schedule. There are hundreds of such schools using our BJC curriculum, and we feel a special duty to those schools. Snap! and BJC are two different projects, and really I'm the only person who's officially on both projects, but we talk to each other a lot (which sometimes means both teams yelling at me, as the common member), and a little bit of BJC money has gone into supporting Snap!.

Why does the “old Snap” cloud storage have to go away?

This is not under our control. Miosoft [sic], which donated storage, bandwidth, and programming support during the first decade of BYOB/Snap!, can't do that any more because we've had enormous growth recently (mostly because of BJC students), and so we've moved to our own cloud storage solution.

I know you mean well, but also it's worth pointing out that there are 0 people working full time on Snap!. There's, obviously, a few of us working part time on things but it makes it really hard to get stuff done as fast as we'd like.

Some of us have been talking about having a community and forum for many many years – it bothers us as much as it bothers you, I'm sure.
It's also worth noting, that it's not perfection that's stopping things from being ready. IMO, we're closer (code wise) than Brian suggests. But, even if the code is ready - releasing a new community site means a lot more in terms of support. Plus, we still somehow need to deal with moderation.

Which is all to say – yes, we hear you. And we're working on it, but there's a lot to be done with not much time to do it all.

cycomachead wrote:

there are 0 people working full time on Snap!.

Well, Jens is, sort of – he's paid full time to do Snap!-related things. But right now that includes a lot of giving talks at conferences and teacher workshops, rather than writing code.

Dale_Mahalko wrote:

I probably should not tell you this.. but not all schools use the same scheduling. Some operate September to June, some operate year-round with about a month off between class sessions. You will never be able to make everyone happy.

Why does the “old Snap” cloud storage have to go away? Just leave it there and rename the URL for it, so that people can still find it and use it when the new thing has been released.

Then you can make the change to the new thing at any time, and merely put a pointer at the top of the page for new thing: “Looking for our previous online edition? Go here!”

And no one will be disrupted other than having to click through to the old version.

For the most part, few noticed that we swapped an entire cloud system from people during a busy time, other than our “maintenance” window. We did this in Feb, and so far it's working fine – but we really tried to do it in December 2017 (things weren't ready) or June 2018, which was too late for Miosoft.

It's true that it's always going to be someone's busy period, but that doesn't mean scheduling isn't important. Selfishly, summers are easiest for the Snap! team to spend more time developing stuff; that includes time to be able to support changes. And, even though there's many non-US users, the (northern hemisphere) summer moths are much lower traffic.
Whenever we have new features, there's always an argument about how soon to release them and who might be frustrated or hindered by changes. Sometimes, but not often, we delay stuff more than I'd like, but we're always trying to balance multiple concerns. This is a passion project, we do it because we like it. No one wants to spend hours, days, or years, on code and not see it go out to users.

bharvey wrote:

cycomachead wrote:

there are 0 people working full time on Snap!.

Well, Jens is, sort of – he's paid full time to do Snap!-related things. But right now that includes a lot of giving talks at conferences and teacher workshops, rather than writing code.

But that's my point! I guess I should have really said “0 people working full time on Snap! ‘product’ development”, and by that I mean products that we want / have control over and not those asked for by some funding source. Jens gets to / has to play all the roles when it comes to Snap!, and I think that's fine, it just means that everyone needs to be aware that Snap! isn't like Scratch in terms of team size and support.

Why can block parameters have types but variables can't?


Leaning on my C programming habits, I was looking to create constants (const or #define) and local persistent variables (static). I wasn't too surprised that you didn't have these. It is unnecessary complexity, another feature a learning reader would have to know to learn from another's program. In my mind, naming magic values and limiting scope is a simplification, but only in my loony mind.

Then I reread the “OOP with Procedures” chapter. In a round-about way, these features can be supported. I also found the <is __ a __ ?> predicate block to check type. You all really did think of everything!

hjcpps wrote:

Why can block parameters have types but variables can't?

Well, first of all, block parameters are variables. But the point of input types is as documentation for the user of a block, who doesn't get to see the best documentation, namely the variable name. Using the built-in input types, you can't say “nonnegative integer,” but if a visible variable name is “number of frobules,” that makes it clear that a nonnegative integer is expected there.

More generally, from your C experience you learned about types as constraints. We're not into that; you can put any input value into any shape slot. (Sometimes it takes some effort, and we don't promise that anything good will result.) That's why in Snap! it's easy to make a heterogeneous linked list, whereas in C it's really hard. And that's why our default input type is Any.

You all really did think of everything!

Thanks. Even static variables: In the Block Editor, right-click on the hat block and choose “Block variables.” These are persistant (static) variables that belong to each instance of a block that you drag from the palette to the scripting area (or into a Block Editor).

I'm not fond of the name or the syntax, but sometimes it's a handy little feature. It'd be better if you could set the initial value to something other than 0. It's on my low-priority list to revisit this feature.

P.S. As for manifest constants, feel free to write a reporter with no inputs that reports the constant value.

When a variable is set to a list, command, etc, it is really set to a reference to the object. If I make a copy using {set list_2 to list_1}, it is a copy of the reference. Both references change the state of the same object. How to I make a copy of the object?

hjcpps wrote:

When a variable is set to a list, command, etc, it is really set to a reference to the object. If I make a copy using {set list_2 to list_1}, it is a copy of the reference. Both references change the state of the same object. How to I make a copy of the object?

You can make a block that iterates over the list and adds each item to a new list (if that's really what you want).