Scratch

In BYOB3, I was wondering:
what if you wanted to create an If < > - Then [ ] - Else If < > - Then[ ] - Else If < > - Then [ ] > and you could always add more Else Ifs.
So far all that seems possible is just to separately have a list of conditions and then the actions.

There probably are other things about this but I think that being able to do something like that should be more obvious how to do it. And I can't think of a very good way to do it using menu button things and not text, like
( Else If condition? then event[ )...


-----------------------------------------------------------------------

Also, I would be really excited if someone figured out a way to make custom blocks that do stuff for visual things, like allowing you to create new visual effects. currently, custom-made blocks let you use the pre-made blocks, as well as several control structures, so that you can neatly bundle some processes that would otherwise use up a lot of workspace and look messy, and your variables and everything are more organized. also it lets you do a lot of fancy stuff with subscripts in super-recursive ways (I get confused if I try to understand why you are trying to put a list inside a boolean inside a pointer to a list of lists of blocks that are directed at the stage or whatever).

However, you cannot introduce other kinds of blocks that would be used in more creative ways. I suppose that that is what panther and the others are about, and byob3 is strictly about scratch for college-level computer scientists or something. But I wish you could make a good, new looks block, something that could map an image into another image based on a user-defined equation. Also a mapping that maps both the position components of each picture element and the color components. and maybe adding in as well some (pseudo-)randomness to get neat effects.
Another really neat idea is that you could have canvasses for drawing other than just the stage. I know smalltalk and squeak support those things, all sprites are canvasses for drawing on by the user, and the stage is a canvass which sprites can draw on. I'm not sure how difficult it would be to take some features which exist inside the costume editor such as flooding and highlighting particular regions, but if each costume had another button, one that said "make into canvas", and then you had a canvas type which could be changed in any way. It is like nesting, you can have costumes each have their own visual effects and they all are used by the sprite.

I just love how you can tell other sprites to carry out scripts by the way!

Last edited by DarthPickley (2011-01-21 19:03:32)

DarthPickley wrote:

But I wish you could make a good, new looks block, something that could map an image into another image based on a user-defined equation.

Hey, no fair editing another question into your message after I answer it! 

But, yeah, it's on the list.  It might not make it into 3.1, but I think the right way to work this is that you can say

ITEM <xcoord> OF [ITEM <ycoord> OF <costume/background>]

and get a list-of-three RGB pixel.  And REPLACE ITEM ditto.  Given that, people can write libraries of "apply this nine-input function to each pixel along with its eight neighbors" or whatever else seems useful.

Also a mapping that maps both the position components of each picture element and the color components. and maybe adding in as well some (pseudo-)randomness to get neat effects.

No, that's not the BYOB Way.     We give you the minimal set of tools you need to be able to write the functions you want in BYOB!  In this case, by extending the domain of the existing ITEM blocks, we have a zero-footprint way to manipulate images.

I just love how you can tell other sprites to carry out scripts by the way!

Thanks!

Yeah, that's pretty cool, rubiks_cube_guy238, but of of BYOB3's grand ideas to to support first class procedures. What if the block(s) that you want to run aren't the shape of command blocks but, say, stored in a variable or in a list element? Or if you want to CALL something?

(Hey, you should be using *real* source code with variable names and comments, not the cryptic decompiled stuff that comes out of shift-R clicking, that's why we're posting dev images    )

scimonster wrote:

On the wikipedia article about scratch, it mentions BYOB, but they spelled Jens' name wrong!
Here's the link: http://en.wikipedia.org/wiki/Scratch_pr … erivatives

I've seen it spelled 'Moenig', but I changed it it 'Mönig' just for fun.

By the way, I am absolutely loving the new experimental beta with first-class sprites. But is there any chance of a (spawn [foo] named [ ]) reporter?

It's the pen, not BYOB. You seem very concerned for its well being ( ), but cool art isn't BYOB's main intention.

Plus BYOB hasn't really been optimized for speed yet (if I understand correctly).

shadow_7283 wrote:

but cool art isn't BYOB's main intention.

That's true.  On the other hand, there is some very cool computer science in picture processing, and I'd be delighted if we could make it practical to implement the equivalent of Photoshop effects plugins in BYOB.

Plus BYOB hasn't really been optimized for speed yet (if I understand correctly).

Indeed.  It's slow as molasses, and 3.1 won't fix that; you'll have to wait for 4.0 in the fall, which, if not blindingly fast, will at least be usable for computationally interesting projects.  (I'm hoping for blindingly fast, but it'll still be an interpreter on top of an interpreter, probably.)

bharvey wrote:

fullmoon wrote:

But is there any chance of a (spawn [foo] named [ ]) reporter?

Nope.  Instead you'll be able to write your own, using

CALL [<SPAWN> OF <FOO>]

to make the new sprite, and then

RUN [[SET <_NAME> TO <whatever>] OF <new sprite>]

to change its name.  At least I think that's how it'll work.  This assumes (Jens?) the ability to drag any block onto the left dropdown slot of the OF block.  And what I've shown as _NAME will be some representation, not yet determined, for implicit attributes of sprites.  (We want a way to make all of them readable and writeable by scripts without having a trillion blocks like Panther.    )

Sounds elegant! I can't wait to see it happen.

JTxt wrote:

And it passed 65536 views! 
.

Funny... 65536 is the exact number of degrees in a circle on the Unreal Engine.

Hi Xavier,

I'm not sure I understand what you mean by not being able to use BYOB's nested sprite feature for designing. There's a (much too short, I know) overview of how to design composites in the BYOB distro, you can find it at the end of the the file named 'BYOB 2.0.pdf'.

You're right, that currently there is no efficient way for a composite to address its parts and vice-versa. But we'll be able to change this with the new first-class sprites extension, by introducing new "system lists".

scimonster wrote:

My solution for the problem of not having 100 new blocks is the Panther CYOB function, along with BYOB.

CYOB solves some problems, but in my view, not the 100-blocks problem.  Once you're programming in Smalltalk, your "palette" is all of the object hierarchy and all of their methods!

Instead, our approach is overloading the existing blocks.  We're already getting a lot more mileage out of the [< > OF < >] block than its original purpose.  We're going to squeeze more out of the SET block, too.  Etc.

Stored procedures will only execute on the owner 

Jens wrote:

Hi Xavier,

I'm not sure I understand what you mean by not being able to use BYOB's nested sprite feature for designing. There's a (much too short, I know) overview of how to design composites in the BYOB distro, you can find it at the end of the the file named 'BYOB 2.0.pdf'.

You're right, that currently there is no efficient way for a composite to address its parts and vice-versa. But we'll be able to change this with the new first-class sprites extension, by introducing new "system lists".

Thanks for the pointer to the 'nested sprites' documentation, Jens.  I couldn't figure out what 'nesting' was!  Now I at least sort of understand.  It's still a bit opaque to me, though.  A couple of quick questions (I know any time you spend answering questions like this taks you a way from 3.1, so feel fre to ignore me):

- I'm not sure the nesting UI is working for me (Ubuntu 10.l10, 3.0.8, scratch 1.4).  As I understand it, in the corral I click on a sprite & drag its icon on top of the sprite into which it should be nested.  There should be a moment when the UI sort of 'clicks', and the subsprite icon shrinks into the highlighted 'parent' (wrong word, i know).  I can't seem to make this happen, so it's hard for me to experiment. 

- After this the subsprite should just track its parent both in x,y  co-ordinates and in direction.  But what happens if its scripts give it independent motion instructions? ahh.. just tried it in toad...  very cool. 

- based on that:  instead of spawning zillions of bullets, could a game just nest a bullet in a gun (sorry, I hate these shooter games, but all my boys want to build them & they illustrate points so nicely...) and, on  say a keypress event shoot out from the gun, hit or miss, and then return invisibly to its starting location?  can it be temporarily unnested from a script, and then renest?  I guess that's something for first-order sprites.

thanks much as always,
matt