On Mon, Jan 19, 2009 at 09:21:02AM -0800, Adam Perry wrote: > On Mon, Jan 19, 2009 at 9:12 AM, James Paige <b...@hamsterrepublic.com> > wrote: > > On Sat, Jan 17, 2009 at 10:30:32AM -0800, Adam Perry wrote: > > James, > > > > I see the documentation for the new slice commands in the xml > plotdict. > > Two things, though: > > > > - The business of containers, slices, and such isn't intuitive. > Could you > > (or someone) create a short tutorial explaining, minimally, how to > get a > > sprite on the screen and manipulate it? > > - All of these commands need to find their way into the wiki as > well. > > > > I'm sure I'm not the only one who's excited about slices but > doesn't know > > where to start. > > Well, lets start here. > > (snip) > > > Okay. Does all of the above make sense? If not, let me know what I need > to clarify, and if so we can move on to talking about containers and > rects. > > Yes, that makes sense. Would be good for the wiki. What about layering? Do > children go on top of parents?
I'll make sure that something like that ends up on the wiki before the next stable release. Hopefully with screenshots and hat-graphics :) Layering is done oldest-to-youngest, with depth-first traversal of the tree. That means that we start with the slice layer Then we draw the first child. (big enemy 1) Then we draw the first child of the first child (big enemy 1's hat) Then we draw the second child (big enemy 2) Then we draw the first child of the the second child (big enemy 2's hat) Then we draw the third child (big enemy 3) And so-on. The upshot is that younger siblings are always drawn on top of older siblings, and that children of a parent are always drawn directly on top of their parent. Once you get use to it, it is pretty easy to understand how to arrange your slices to make them draw in the order you want. Containers can be great for that. A container is simply an invisible slice for use as a parent to other slices that you want to group together either for looping or for controlling draw-order. You can change the width and height of a container however you want. I think I should mention alignment and anchors now. So, you already know that a slice has a relative x/y position to its parent. By default, a slice is aligned to the top left corner of its parent, and it is anchored by its own top left corner. For some purposes, positioning everything according to top left corners is all you are going to need, but sometimes it becomes more convenient to position a slice in other ways. Check out this example where I attach a four NPC sprites to a container, one on each corner variable(box, sl) box := create container(150, 150) sl := load walkabout sprite(4) set parent(sl, box) # this one starts in the top left sl := load walkabout sprite(5) set parent(sl, box) set horiz align(sl, edge:right) set horiz anchor(sl, edge:right) # put this one in the top right sl := load walkabout sprite(6) set parent(sl, box) set vert align(sl, edge:bottom) set vert anchor(sl, edge:bottom) # put this one in the bottom left sl := load walkabout sprite(7) set parent(sl, box) set horiz align(sl, edge:right) set horiz anchor(sl, edge:right) set vert align(sl, edge:bottom) set vert anchor(sl, edge:bottom) # put this one in the bottom right Now each of these four sprites will be arranged at the corners of a 15x150 container. Notice that we did not change the x/y of any of thse slices? If you use "slice x" and "slice y" you will see that they are still all at 0,0 but if you check with "slice screen x" and "slice screen y" you will see that they now all have been moved. Now what gets really cool is if you resize the container. variable(i) for(i, 0, 49) do, begin set slice width(box, slice width(box) + 1) set slice height(box, slice height(box) + 1) wait(1) end The sprites attached to the corners will move automatically as you resize the box! Does that make sense? --- James _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org