So I just added two enemies moving on the same platform and when I shoot one, after several seconds the other one disappears with out it hitting anything and vice versa. I know that it is something to do with the collision because I didn't draw the one of the enemies, I shot one and I didn't die when stood on the platform for a while. But I can't see what is wrong with it. Especially as the other enemies work fine (Removed some irrelevant code).
I believe part of the problem is in your collideArrow function:
if((arrow.x > enemy.x + enemy.width) || (arrow.y > enemy.y + enemy.height) || (enemy.x > arrow.x + arrow.height) || (enemy.y > arrow.y + arrow.height) && (enemy.live) && (arrow.live))
What you probably want it to be is:
if((arrow.x > enemy.x + enemy.width) || (arrow.y > enemy.y + enemy.height) || (enemy.x > arrow.x + arrow.height) || (enemy.y > arrow.y + arrow.height) || !(enemy.live) || !(arrow.live))
I think that's very wrong....your basically saying "if the arrow is further right or higher than the enemy or the enemy is further right or higher than the arrow"...doesn't make sense.
Also someone's advice is terrible!
Thanks, someone, got it working 
What do you mean dizzy? The collision works fine, simple bounding box collision.
It seems like you're just checking each corner in isolation when you should be checking to see if the arrow is inside the bounding rectangle.
No, that ain't no bounding box collision! That's exactly what I said in my post. If you made bounding box collision with that code in someones post, I'll fry myself.
I think what you want to be doing for collision detection is something like the first line of the function I posted over here.
What you have is slightly similar, but wrong in the end.
You should also separate the enemy.live and arrow.live checks from the actual collision detection itself to make things clearer.
if(!enemy.live || !arrow.live) return; //now, check for collision
I have no idea what any of you are talking about any more. Since when has it ever been possible to do a bounding box collision just using OR's....none of the code you're posting works!?!?
Dizzy Egg is right.
The two forms are logically the same:
if((arrow.x > enemy.x + enemy.width) || (arrow.y > enemy.y + enemy.height) || (enemy.x > arrow.x + arrow.height) || (enemy.y > arrow.y + arrow.height) || !(enemy.live) || !(arrow.live)) return false; return true // or: if((arrow.x <= enemy.x + enemy.width) && (arrow.y <= enemy.y + enemy.height) && (enemy.x <= arrow.x + arrow.height) && (enemy.y <= arrow.y + arrow.height) && (enemy.live) && (arrow.live)) return true; return false
So it turns out the only Allegroid left with an IQ is Karadoc, because the rest of you are missing the point....bounding box would imply checking within a box!
To me also does not look like a bounding box collision. 
EDIT: ah OK, the expression is NEGATED by the return values so the logic AND is susbstituted by the equivalent negated logic *N*OR.....haven't checked deeply but MAY be ok.
Apparently with all the fuss over logic no one's noticed that it should be arrow.width on the second line.
Dizzy, I'm sorry but this code is ok... there's a little bug that uses height instead of width once (he couldn't notice it if they are equal), but otherwise it's intended to check if two rectangles overlap :
One rectangle goes
- horizontally from (arrow.x) to (arrow.x + arrow.width)
- vertically from (arrow.y) to (arrow.y + arrow.height)
The other rectangle goes
- horizontally from (enemy.x) to (enemy.x + enemy.width)
- vertically from (enemy.y) to (enemy.y + enemy.height)
Nope. According to his logic, if my arrow is farther right OR higher than the enemy, there's a collision. No box involved.
Nope. According to his logic, if my arrow is farther right OR higher than the enemy, there's a collision. No box involved.
You seem to fail to see that the return statement reached when the condition is true returns false. That code checks for all cases where there is no collision, and returns true otherwise.
AABBCollision can be carried out checking if the two boxes overlap, or if the DO NOT overlap, but in that case you have to return negated values of course.
That is what I failed to see as well (the xchange between return false and return true 
)
...ooooh....tits. My bad.
I guess Dizzy Egg and I were wrong all along. 
I had only looked at the snippet someone972 posted, and I wrongly assumed the condition was to test for a collision rather than for a miss.
Ha, I just came back to this thread to see if it got resolved and I got a good chuckle from the stream of posts .
EDIT:
If all that is needed is to check whether two bounding boxes collide, the negated method works fine and is actually a little more optimized since it bails early if one of the checks fails. Of course it's a nearly worthless optimization.
Both methods 'bail early' if one of the checks fails.
Whoops, that's true. Looks like I'm not thinking strait today either 
.
I dunno why, but I just like the "opposite way" of checking for bounding box collision. My brain wraps around it easier.
Either way, were you able to figure it out, DJLad16?