PDA

View Full Version : [FMX] getBounds();



andr.in
September 7th, 2003, 10:49 AM
How to use getBounds() ? I more-or-less know what it does.. I think... but I have no idea how to use it whatsoever...
:hat:

Voetsjoeba
September 7th, 2003, 11:01 AM
http://www.macromedia.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary523.html ;)

andr.in
September 7th, 2003, 11:02 AM
I already read that... it doesn't explain it all... :*(

senocular
September 7th, 2003, 11:17 AM
what do you mean by how :-\ are you just curious on how it works or do you think you need it for something?

Voetsjoeba
September 7th, 2003, 11:23 AM
Description
Method; returns properties that are the minimum and maximum x and y coordinate values of the instance specified by MovieClip for the targetCoordinateSpace parameter.

I've attached a little FLA that shows about it.

andr.in
September 7th, 2003, 11:46 AM
I'm afraid I need it for something... :-\
Like the "maze" sample that came with flash... I want to ceate something similar.. you move a dot that cannot go through objects... but I got confused with all those hitTests and getBounds and how to combine them (yes I've read the hitTest tut)... :*(

senocular
September 7th, 2003, 11:50 AM
Ill expand since that is only a small part of get Bounds ;)

Get Bounds basically gives you a way to find the lefts and rights, and tops and bottoms of your movieclips. Conventional properties dont give you this information. The closest thing you have are _x and _y and with that _width and _height. Those alone, however, wont tell you how far left your movieclp extends. However, if your movieclip's registration point is centered, you could find out its left by using _x - _width/2; but thats not always the case. Also, that only works for the left of the movieclip in its parent scope, getBounds can get it in any scope in the sense that it also works as a local to global as well.

One thing to note is that getBounds works with the bounding box of a movieclip, and not its visible area. Because of that, something like a rotating circle an have fluctuating values because, although its a circle and visibly doesnt change when rotating, its bounding box is square and does change.

By default getBounds gets the bounds of the clip within itself which is the same as saying myClip.getBounds(myClip). This is seen in Voetsjoeba's example. Within itself pretty much means as the clip was made in its own timeline. Scaling or rotating the clip (which in essense occurs in the clips _parent timeline) will have no effect on the getBounds called in this manner. This is probably best used for attaching movieclips with a little more accuracy as you can easily find the extents of a clip internally using getBounds in this respect.

The more common use of getBounds is finding the bounds within the clip's parent - myClip.getBounds(myClip._parent). This puts the bounds returned in the same coordinate space as the _x and _y properties of that clip. This is the more generally percieved left, right, top and bottom values. In fact, in Tricks of the Trade (http://www.kirupaforum.com/forums/showthread.php?s=&threadid=14268) I posted some functions that will add _left, _right, _top, and _bottom properties to movieclips that use getBounds to get those values. Here, scale and rotation does have an effect on how getBounds reacts as it changes the clips boundings in the _parent clip. This proto http://proto.layer51.com/d.aspx?f=944 can help you see some of that and how it works - it uses getBounds to draw a movieclips bounding box.

Beyond itself and its parent, the argument in getBounds just gives you bounds locations in any other movieclip should you need them. Again, this is just getting into local to global/ global to local kind of stuff here. Same idea, just encapsulated in the getBounds function

senocular
September 7th, 2003, 11:53 AM
I hate that stupid maze thing :P I tried so hard to beat it and then I finally opened it up to find out the computer had its own motion guide leading it right through perfectly BAH! heh

Mazes like that, though, are probably better handled using a tiles kind of approach. That way, you wont have to worry about hittest at all and just whether not a position is valid - though depending on how big your maze is, hittest might be the way to go anyway - movement method too plays a part in how to handle that as well. How you move can be a big part in how you handle movement... though after just saying that I guess its blatently obvious heh

Voetsjoeba
September 7th, 2003, 11:57 AM
If you'd use



if (this.hitTest(_root.othermovie)) //something


then hitTest will only be true when the registration point of _root.othermovie hits this. If you hitTest the bounds, like they did in the maze, it will stop when a edge of _root.othermovie hitTests with this =)

*Beaten by Sen

andr.in
September 7th, 2003, 12:17 PM
ok thank you for you patience ppl :) but actually... I still don't get how the maze is done... (the not-moving-through-walls part) ;)

don't mind me.. I'm just dumb

I hate that stupid maze thing I tried so hard to beat it and then I finally opened it up to find out the computer had its own motion guide leading it right through perfectly BAH! heh
lol me too! I tohught there was some hard-***** AI behind that... :P

senocular
September 7th, 2003, 12:31 PM
the maze example uses the _parent getBounds getting the left, right, top and bottom (xmin, xmax, ymin, and ymax respectively) of the player clip in its parent or _root. using those boundries, it can check to see if any one of those sides touches (hitTests) with the maze walls. hitTest, however, doesnt work necessarily with 'sides' - it uses either movieclips on movieclips or a single point on a movieclip. The maze takes the single point approach but uses one point for each side. So you see hitTest being used 4 times, once for each side. Each hitTest takes a side by getBounds and uses it with either _x or _y (to center that point on the side) and checks to see if that side is touching a maze wall. If it DOES hit, then the movieclip is sent back in the direction it moved - the movement happening before the actual wall collision. So ...
if (Key.isDown(Key.DOWN)) {
_y += 1;
}
will move the _y of the square (the player) down 1. The
if (walls.hitTest(_x, getBounds(_root).yMax, true)) {
_y -= 1;
}
is then checked to see if it hits, and if so move back 1 y canceling out that movement.

andr.in
September 7th, 2003, 12:59 PM
ok.. now it's coming to me...

if (walls.hitTest(_x, getBounds(_root).yMax, true)) {
"_x" is just some x value to be checked right.. or sth?
"getBounds()" thing there is the rightmost _x value of the umm... "player's dot" !???
and "true" is something with "to bounding box or not to bounding box"...