Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Need some help with 2D collision

Author
Message
Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 29th Jun 2010 03:07
It has been a couple of years since the last time I used DBPro but I thought I should give a try again.

I'm trying to make a top down shooter game in 2D. Something like "Into The Eagles Nest". http://www.abandonia.com/en/games/491/Into+The+Eagles+Nest.html

I'm having some trouble with the collision (Player vs. Walls). The map data is stored in an array and I was going to check the player position against that. That was no problem when the player only could move up, down, left or right. But since I re-wrote the player movement (left and right rotate the player sprite and up moves the player forward following the angle of the player sprite) I'm having some problems figuring out the collision.

Here's what I got so far (no checking for collisions). I'm not sure how to use the angle of the player to check for collisions. Any help would be appreciated.

Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 29th Jun 2010 20:01 Edited at: 29th Jun 2010 20:05
Ok. I got some of the collisions to work.

The collision works against the walls on the left, right, top and bottom side, but it's not quite right when it comes to the walls in the middle (it depends on the angle of the player), and I'm not sure how to fix it. Any suggestions?

And is this a good way of doing collision detection? So far it seems quite complicated (at least for a beginner like me). Is there a simpler solution and I'm just over-complicating it?

Here's the code. You don't need any media files to try it.

Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 30th Jun 2010 07:09
Normal SPRITE COLLISION doesn't do well with rotated sprites. You can do a search for "pixel perfect collision" in the thread subject search box at the bottom of this message. Pick one of the many methods already on the forums for perfect collision even while rotated.

Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 30th Jun 2010 10:03
he's not using sprite collision, and it's not detection it's response that's the issue.


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 30th Jun 2010 19:09 Edited at: 30th Jun 2010 19:17
Yeah I noticed. That's why I used the word "normal".

When he asked "Is there a simpler solution and I'm just over-complicating it?"... I informed him about pixel perfect collision since he wants to rotate his sprites. It's easier to switch methods from what he's doing to pixel perfect collision for better response.

Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 30th Jun 2010 19:34
Thanks for the answers Neuro Fuzzy and Grog Grueslayer.

I'm going to take a look at pixel perfect collisions but I'm not sure if that's what I need here. But then again, maybe I need that when I start adding bullets to my game.
Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 30th Jun 2010 20:56
there isn't really a simpler method, so don't worry, you're not really overcomplicating it.

One thing though... you're using squares and sliding collision with rotated squares... that's not supposed to be simple. If you don't want a corner to intersect the wall at all, then you have to place limits on rotating the square, as well as moving it while sliding everything. That's a formula for complication, and when you get to that point, you might as well make a full, general polygon collision engine.

Try treating everything as square-circle collision - then you don't have to worry about the rotation of the square, and you don't have to do as much stuff like linear interpolation and parametric systems of equations to find where lines intersect and how far to move them.

Just in case you want to know - circle<->circle collision and square<->square (non rotated) are the absolute easiest to handle.

I'll try to come up with something for circle-square sliding collision in a bit (going away from computer rly soon).

also, I don't think that pixel perfect collision is what you're looking for at all. Pixel collision is when you want to build a physical shape from a 2d image, but you already have nice geometrical models of everything (IE you know all the vertices of every square and all their relationships).


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 30th Jun 2010 23:35
Thanks again Neuro Fuzzy.

I'm not sure what you mean by circle<->circle and square<->square collision. It would be great if you could give me a simple example.
29 games
18
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: not entirely sure
Posted: 2nd Jul 2010 02:51 Edited at: 2nd Jul 2010 02:54
First, very cool collision code.

I think what Neuro fuzzy is talking about when he says "circle<->circle" collision is the two shapes that are colliding are both circles.

A simple example of this is:




Square<->square collision would two squares colliding.

For squares that are parrellel to the XY axis this is relatively simple but if either square is rotated things get a little more tricky which is what you've discovered.

I've been doing some maths collision of my own recently, if you go to this thread (on the DBC board):

http://forum.thegamecreators.com/?m=forum_view&t=167811&b=10

there's a 2D demo on the last post that has a function that detects point <-> "four-sided-shape" collision that you could adapt to work with your program.

Essentially your trying to work out if the corner of the map tile is in the rotated box that the player controls. The sliding bit, that's going to be a little more tricky.

There's also a pdf (on the first post) that goes through the maths I came up with for circle <-> line sliding collision, were the line can be at any angle, which gives you an example of how complicated this can get. Unfortunately the demos that use this maths are in DBC and will not work in DBP.

What I tend to find is that detecting whether or not two things have collided is the easy bit and it's the resolution: sliding, bouncing off etc, that is more difficult.

Hope this helps.
Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 2nd Jul 2010 03:28
Thanks 29 games.

I understand the circle<->circle collision and the square<->square collision now. I used square<->square collision in an earlier version of my code before I decided the player should be able to rotate. I just didn't know what it was called.

I've already found the thread you mentioned but I missed the last post so thanks letting me know.

I also found a lot of source code over at http://underwaredesign.com/prod_detail.php?rnd=287063805&id=20

So I guess I need to figure out a way to detect circle(player)<->square(wall), as Neuro Fuzzy suggested, or maybe circle(player)<->line(one side of the wall).

I need to get some sleep now but at least I managed to progress in some other areas of the game today (loading maps from external .bmp files and screen scrolling) yay
Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 2nd Jul 2010 05:34
It's not collision detection really that's the problem, it's collision response.

Circle-circle collision and response is super duper easy. check this video out:
http://www.youtube.com/watch?v=28G7k0MTfxg
You might think that the circle collision stuff would be a little hard to do, but the detection (using the same method as 29 games said) was about 3 lines, and the response was about 5 simple lines (you take one circle's position, subtract the other circle's position, normalize it, multiply it by how far they've intersected, and add half that to each circle's position).

Sorry for being so little help though. Actually I did spend a while making a system I thought should work, but it didn't


Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 2nd Jul 2010 06:30
I'm not so sure if the collision response will be that difficult in my case since my wall consists of non rotated squares.

A simplified version would be something like this:
If a collision is detected you got 3 choices.
Choice 1: move only on the X-axis
Choice 2: move only on the Y-axis
Choice 3: don't move at all

And that's what I'm using now. So if I can figure out the collision detection I'm good to go (unless I've missed something).
Neuro Fuzzy
17
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 2nd Jul 2010 21:44
OK, I got the code I was trying to use working. I guess I just had some errors with switching x and y variables and not paying attention

your collision response isn't totally correct. You can't just limit the axis - what about moving away from the wall? What about if the circle only intersects with a corner? Then it'll follow a quarter circle path.

Basically what i did is this;

1. check if the center of the circle is directly above or below the square
--if true: find out by how far the circle is in the square
--move the circle that amount up/down. [end function]
2. check if the center of the circle is directly right or left of the square.
--if true: find out by how far the circle is in the square
--move the circle that amount right/left. [end function]
3. check if the distance from the circle's center to the closest corner is less than the radius.
--if true: find out how far the circle is in the square
--move the circle that amount away from the square [end function]
4. if the function is still running, there is no collision [end function]

#3 sounds a bit tricky, but it really isn't with some basic vector math. Where V is the circle's position, C is the corner's position, and |N|=sqrt(Nx^2+Ny^2) (length of vector N)

to respond to the collision:
first, find the length from the circle to the corner
d=|V-C|
then, find the direction in which you'll be moving the circle (normalized, meaning length of one)
D=(V-C)/d
then, find the magnitude that the circle intersects the square
m=r-d (r>d if there is an intersection)
the circle's new position (V') is the circle's position pushed back in the direction of intersection by the depth it intersects, so
V'=D*m
=(V-C)/|V-C|*(r-|V-C|)




Is't life, I ask, is't even prudence, to bore thyself and bore thy students?
Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 3rd Jul 2010 00:49
Thanks Neuro Fuzzy.

I'm a bit busy with some other things right now but I'll check out your code later. I really appreciate the help.
Ranietz
AGK Gold Backer
20
Years of Service
User Offline
Joined: 2nd Sep 2004
Location: Norway
Posted: 3rd Jul 2010 23:29
I had the time to look at the code today and I rewrote it a bit to better fit my needs. I still don't fully understand the collision function but I'm gonna try to implement it into my current game code.

Thanks again Neuro Fuzzy.

Heres the code after I rewrote some parts of it.

Login to post a reply

Server time is: 2024-11-23 14:06:19
Your offset time is: 2024-11-23 14:06:19