hitTest?

[Psytrix]

ok now that i have my hero, how do i make objects that he cant go thru...i guess this is where i learn hitTest?

[senocular]

did you read the sticky in this forum yet?

[Psytrix]

of course. but how would does it work, if you put a hitTest between two objects they cant go into one another? bc i dunno how you would say on hitTest hero cant go into wall.

[senocular]

did you go to my link in the other thread you posted about key controls?

[Psytrix]

o i missed it, sorry. im checking it out now
here my little question:

when two movieclips touch

onClipEvent (enterFrame) {
if (hitTest(_root.hero)) {
// actions
}
}

what are the actions that keep them from goin into each other?

[GameDev]

when two movieclips touch

onClipEvent (load){
 speed = 15;
}


onClipEvent (enterFrame) {
 if (this.hitTest(hero){
   if (dir == "left"){
   this._x = this._x+speed
  }
}
}

just add the appropriate code for other directions,

-Tyler

[senocular]

whether or not you actually went to that other link, Ill throw most of it back here and get into how it works.

onClipEvent(load){
	vy = vx = 3
	bounds = {L:50,R:250,T:50,B:250}
	obstacles = [_parent.clip1, _parent.clip2, _parent.clip3]
	gotoAndStop(2);
}
onClipEvent(enterFrame){
	dx = Key.isDown(Key.RIGHT)-Key.isDown(Key.LEFT)
	dy = Key.isDown(Key.DOWN)-Key.isDown(Key.UP)
	
	if (d=(dy*3)+dx) gotoAndStop(d+15)
	else if (_currentFrame > 10) gotoAndStop(_currentFrame-10)

	p_x=_x; p_y=_y
	l = obstacles.length
	_x = Math.min(Math.max(_x+vx*dx, bounds.L), bounds.R)
	for(i=0;i<l;i++) if (obstacles[i].hitTest(_x,_y,true)){_x = p_x; break;}
	_y = Math.min(Math.max(_y+vy*dy, bounds.T), bounds.B)
	for(i=0;i<l;i++) if (obstacles[i].hitTest(_x,_y,true)){_y = p_y; break;}
}

I know it looks complicated but Ill walk through it. Actually, since we're dealing with hitTest, Ill knock out the character directions code, and even the boundry code since I doubt you'll be confining your character to a box (I assmue link needs to be able to exit at the sides to change screens) ...

onClipEvent(load){
	vy = vx = 3
	obstacles = [_parent.clip1, _parent.clip2, _parent.clip3]
}
onClipEvent(enterFrame){
	dx = Key.isDown(Key.RIGHT)-Key.isDown(Key.LEFT)
	dy = Key.isDown(Key.DOWN)-Key.isDown(Key.UP)

	p_x=_x; p_y=_y

	l = obstacles.length
	_x += vx*dx
	for(i=0;i<l;i++){
		if (obstacles[i].hitTest(_x,_y,true)){
			_x = p_x;
			break;
		}
	}

	_y += vy*dy
	for(i=0;i<l;i++){
		if (obstacles[i].hitTest(_x,_y,true)){
			_y = p_y;
			break;
		}
	}
}

So, from the top. vx and vy are our velocities for x and y. vx and vy because its shorthand and if you can remember yur shorthand then it can make for a little cleaner code when you do all the rest. I usually use abbreviations which make sense like vy for velocity along y. I figure it makes sense... though its not needed. Since they are both the same value, I can have them both on the same line equaling the same number. Im making them both 3. This means every frame if Im moving this guy, he'll move 3 pixels either left and right or up and down depending on what keys Im pressing.
"differential of x"

obstacles = ... This is an array of the obstacles (movieclips) that this clip has to avoid, or stop when hit. Now, an easy way to do this is by keeping all of your obstacles in one movieclip and test for a hitTest on only that one movieclip. That wouldnt require the loops used further along in the code and would be less a strain on flash, but thats not always a viable solution so I planned for a kind of "worse case scenario" in this example.

Next is the enterFrame where all the action takes place and things are put to work. The first 2 lines get dx (differential of x) and dy (differential of y). Actually thats not completely accurate since at this point its only getting the direction. The real differential is with the vx/vy (velocity) added which gives you the actual displacement of movement, or the actual difference in location which dx and dy represent. Anywho, the idea behind these 2 lines is to avoid all that if/else junk checking for the keys directly. Key.isDown returns either true or false depending on whether or not the key specified is pressed or not. So if the right arrow key is being pressed, Key.isDown(Key.RIGHT) is true. If not, its false. Now to math, true is the same thing as 1 and false is 0, and we are using these values in a simple math formula
Key.isDown(Key.RIGHT)-Key.isDown(Key.LEFT)
which will evaluate to true-true or false-true etc. But, like I said, to math, true is 1 and false is 0 so what we're really doing is saying 1-1 or 0-1 etc which will give us one of three numbers, -1, 0 and 1, which if you figure it out (or just take my word for it) will give you a -1 when left is pressed, 0 when neither or both are pressed and 1 when right is pressed, effectively giving us our directions in two lines, one for horizontal and one for vertical.

After that is a lonely p_x and p_y definition. These are two values which represent our previous _x ad previous _y. What the following lines do is move the character to where it should go next frame and checks to see if the character is hitting any of the obstacles, if so, then move it back to its p_x and p_y making so it does move at all when the frame is actually played.

And that code is the for loops. This does the check on both _x and _y but Ill just go through _x since _y is pretty much the same thing. First l is set. l means length; it just holds the length of the obstacles array so its shorter (and a little faster). Then the actual movement is applied to the clip with _x += vx*dx; This changes _x and adds to it the velocity times the direction. If our direction ended up being -1, then when our velocity is added, we end up with -3 and we move the clip -3 places along the _x which is to the left 3 places. If direction was 1, that would give 3 and wed move to the right 3 places. That sets the temporary movement. If we find that we are hitting something in this new spot, we have to go back to our old position, though if we arent hitting anything, we can stay right here. So to check the for loop runs for(i=0;i<l;i++){ which just says, for every clip in the obstacles array, do something in this loop. What is done is that hitTest check
if (obstacles[i].hitTest(_x,_y,true)){
which checks to see if any of the obstacles is intersecting with the centerpoint of this clip (_x and _y representing this clips position, or centerpoint). You could just put "this" in the hitTest
if (obstacles[i].hitTest(this)){
which would check the bounding boxes of the clips, but I prefer the centerpoint since in reality anyone can lean over an obstacle a little so I think it makes sense So if the hitTest is true and we are actually hitting and obstacle, then we send the position back to the previous position with _x = p_x; and use a break; command to exit the for loop since we no longer need to check for any obstacles (hense theres no reason to keep going through the loop); If no obstacles are found to be touching the clip, then it remains in the new position and everyone is happy and moving right along in the game

Now I said before that its easier to keep all your obstacles in a single clip, which, if that is the case, instead of the for loop all youd need to do is have one check
if (obstacles.hitTest(_x,_y,true)) _x = p_x;
where obstacles would be the clip where all your obstacles would be in.

Easy right? ok maybe not, especially since it took this long to explain but its here and hopefully someone might learn something new.

[magnetos]

hey senocular i wuold like to know your opinion on this one
take a look at this
http://digilander.libero.it/magneto1/Scrollnice.swf
http://digilander.libero.it/magneto1/Scrollnice.fla

i am sure Psytrix might find it usefull too

[senocular]

yeah Ive seen that before, a while ago. same basic idea, but the world is moving around the character and not the character in the world

[magnetos]

Originally posted by senocular
yeah Ive seen that before, a while ago. same basic idea, but the world is moving around the character and not the character in the world

yes senocular but isn t that a good way game wise speaking?
i mean all you have to do is add all your moving character inside the huge moving mc and when you move everything moves with you

of course you gonna have to do some globaltolocal calculations for any eventual enemy inside the huge moving mc
obviusly enemy shouldnt move unless they are inside the player viewble area

or is that a better way?

sorry to bother you with this but scrolling and hitTesting sometimes
is a pain in the arse

[senocular]

yep, thats pretty much how its done

[Psytrix]

senocular im gonna read over that code again and again for the next few days...ill be using it no time, well i hope so.

[Psytrix]

here is some code i saw made my ed mack in marmotte's rockypack

RockyLimit = _root.SpritesBackground.rocky.limit.getbounds(_root.SpritesBackground.rocky);
	function RockyMove(x, y) {
		with (_root.SpritesBackground.rocky) {
			if (!_root.GraphicsBackground.Graphics.limit.hittest(_x+x+rockylimit.xmin+1, _y+y+rockylimit.ymin+1, true)) {
				if (!_root.GraphicsBackground.Graphics.limit.hittest(_x+x+rockylimit.xmax-1, _y+y+rockylimit.ymin+1, true)) {
					if (!_root.GraphicsBackground.Graphics.limit.hittest(_x+x+rockylimit.xmin+1, _y+y+rockylimit.ymax-1, true)) {
						if (!_root.GraphicsBackground.Graphics.limit.hittest(_x+x+rockylimit.xmax-1, _y+y+rockylimit.ymax-1, true)) {
							_x += x;
							_y += y;
						}
					}
				}
			}
		}
	}
}

how does this work?