Collision Detection

What is the best way, in your opinion to handle collision detection in a 2d-sidescroller? Right now my 653 lines of code that are more thrown together than anything are not doing the job I want them to do.

I want to make a more simplified version and I am beginning to. However I want to know if you think that I should make a base class for all images in my game- then derive everything from there; or perhaps make a class for collision detection and move from there. Or would it be better to make a function for collision detection and have a separate collision handling function?

My code now consists of a sprite class, a timing class, a basic loading class, and my main file. I have implemented gravity, basic movement, jumping, animation, timing, and scrolling backgrounds- but I would like to clean everything up- so what would you experts recommend?

Sorry for all of the questions- I’m just really excited to continue to work on this- but I don’t want to do anything unintelligent! =D------------------------
#include <sig>

using ultifinitus::signiture;

int main(int argc, char* argv[]){
sigout << coolest signature ever;
}

Is there a reason you don’t want to use existing sprite implementations?
I think there are many around. The only one I know is kyra and I think it handles collision as well.
P.S. I’m not an expert in sprite.

/_/_/_/_/_/_

www.huaonline.com

My Homepage is my Castle— On Mon, 1/3/10, ultifinitus wrote:

From: spy4hearts@gmail.com (ultifinitus)
Subject: [SDL] Collision Detection
To: sdl at lists.libsdl.org
Received: Monday, 1 March, 2010, 4:37 PM

What is the best way, in your opinion to handle collision detection in a 2d-sidescroller? Right now my 653 lines of code that are more thrown together than anything are not doing the job I want them to do.

I want to make a more simplified version and I am beginning to. However I want to know if you think that I should make a base class for all images in my game- then derive everything from there; or perhaps make a class for collision detection and move from there. Or would it be better to make a function for collision detection and have a separate collision handling function?

My code now consists of a sprite class, a timing class, a basic loading class, and my main file. I have implemented gravity, basic movement, jumping, animation, timing, and scrolling backgrounds- but I would like to clean everything up- so what would you experts recommend?

Sorry for all of the questions- I’m just really excited to continue to work on this- but I don’t want to do anything unintelligent! =D

#include

using ultifinitus::signiture;

int main(int argc, char* argv[]){

sigout << coolest signature ever;

}

-----Inline Attachment Follows-----


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

ultifinitus wrote:

What is the best way, in your opinion to handle collision detection in a
2d-sidescroller? Right now my 653 lines of code that are more thrown
together than anything are not doing the job I want them to do.

I want to make a more simplified version and I am beginning to. However
I want to know if you think that I should make a base class for all
images in my game- then derive everything from there; or perhaps make a
class for collision detection and move from there. Or would it be better
to make a function for collision detection and have a separate collision
handling function?

My code now consists of a sprite class, a timing class, a basic loading
class, and my main file. I have implemented gravity, basic movement,
jumping, animation, timing, and scrolling backgrounds- but I would like
to clean everything up- so what would you experts recommend?

Sorry for all of the questions- I’m just really excited to continue to
work on this- but I don’t want to do anything unintelligent! =D

This is not an easy question to answer… Many books have been written on
the subject. In collage, a professor offered the simplest of algorithms
for collision detection for one of our programs:
Go through and calculate all movement for all actors. Then, if any actor
crosses bounds of another actor, deny that actors movement.

That’s about as simple as you can get… I think.

My solution was a bit too complicated for everyday use… =( So I don’t
recommend it.

I had a 3-Pass process… A collision class managed everything for how I
did it.
Pass 1- Identify (through axis-oriented bounding boxes) any collision that
MIGHT occur.
Pass 2- Solve collisions from the list in Pass 1, using shapes specified.
Pass 3- Solve physics responses for collisions that occurred in pass 2.
(i.e., two billiard balls next to each other and the cue hits the one in
front, the one behind will react as well.)

I’m not being very clear, I apologize. But, I’m sure others will have a
world of better info then I do. I hope some of this helps!

You’re asking the right design questions, but you really need to be
asking them of yourself! Nobody else here knows your needs but you ;)On Mon, Mar 1, 2010 at 12:37 AM, ultifinitus wrote:

What is the best way, in your opinion to handle collision detection in a
2d-sidescroller? Right now my 653 lines of code that are more thrown
together than anything are not doing the job I want them to do.

I want to make a more simplified version and I am beginning to. However I
want to know if you think that I should make a base class for all images in
my game- then derive everything from there; or perhaps make a class for
collision detection and move from there. Or would it be better to make a
function for collision detection and have a separate collision handling
function?

My code now consists of a sprite class, a timing class, a basic loading
class, and my main file. I have implemented gravity, basic movement,
jumping, animation, timing, and scrolling backgrounds- but I would like to
clean everything up- so what would you experts recommend?

Sorry for all of the questions- I’m just really excited to continue to work
on this- but I don’t want to do anything unintelligent! =D


#include

using ultifinitus::signiture;

int main(int argc, char* argv[]){
sigout << coolest signature ever;
}


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


http://codebad.com/

There are quite a few approaches. Wikipedia glances at a few.

I’ve often used methods such as Grouping objects by sector and only
comparing objects in the same sector. This works best when you have
alot of objects that dont move.

If you have objects that move alot you could calculate the sector when
you move. I have in the past just used the x and y coordinates of
object locations divided by 200 or so to give a corse grid of sectors.

It is often all about reducing the number of comparisons.

IanOn 1 Mar 2010, at 05:37, “ultifinitus” wrote:

What is the best way, in your opinion to handle collision detection
in a 2d-sidescroller? Right now my 653 lines of code that are more
thrown together than anything are not doing the job I want them to do.

I want to make a more simplified version and I am beginning to.
However I want to know if you think that I should make a base class
for all images in my game- then derive everything from there; or
perhaps make a class for collision detection and move from there. Or
would it be better to make a function for collision detection and
have a separate collision handling function?

My code now consists of a sprite class, a timing class, a basic
loading class, and my main file. I have implemented gravity, basic
movement, jumping, animation, timing, and scrolling backgrounds- but
I would like to clean everything up- so what would you experts
recommend?

Sorry for all of the questions- I’m just really excited to continue
to work on this- but I don’t want to do anything unintelligent! =D

#include

using ultifinitus::signiture;

int main(int argc, char* argv[]){
sigout << coolest signature ever;
}


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

ultifinitus wrote:

What is the best way, in your opinion to handle collision detection in a 2d-sidescroller?

it depends!!

give a look to these tutorials

http://lazyfoo.net/SDL_tutorials/lesson17/index.php
http://lazyfoo.net/SDL_tutorials/lesson18/index.php
http://lazyfoo.net/SDL_tutorials/lesson19/index.php

MandarX------------------------
http://mandarx.xoom.it/index.php?lang=eng

If you like alternative solutions. You could make a collision map.

At any given moment you know what position your character is in relation to
the entire world based on user input.

Say if your guy moves right. Then he announces to the world, I have moved
this much to the right.

The world, which is running in a loop then tests that position against
coordinates in the collision map which is really a big list.

The state of the PC is determined by its relative location. Different areas
of your world might have the following flags.
UP | NOUP | DOWN | NODOWN | KNOCKBACK

The flags can also have default values stored on the PC, so large areas that
are the same can store their info in the PC and aren’t needlessly rechecked.
Then any sprites you add can affect the PC by changing the state of world.
So basically heres the order
1.Starting point determines the default flags.
2.Default flags determine what input can be accepted.
3.User input controls the PC state. Location is included in that state.
4.World(in its own loop/thread) checks the location and determines if its
time for a change in flags.
5.PC responds to change in flag(if any) by blocking or accepting user input
and displaying an animation.

This might and might not be easier for you . You would probably need some
really tight velocity control for projectiles.On Mon, Mar 1, 2010 at 4:32 AM, mandarx wrote:

ultifinitus wrote:

What is the best way, in your opinion to handle collision detection in a
2d-sidescroller?

it depends!!

give a look to these tutorials

http://lazyfoo.net/SDL_tutorials/lesson17/index.php
http://lazyfoo.net/SDL_tutorials/lesson18/index.php
http://lazyfoo.net/SDL_tutorials/lesson19/index.php

MandarX


http://mandarx.xoom.it/index.php?lang=eng


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I have never thought, for some strange reason to lower the number of collision checks per frame… But it makes sense! I have a solution that while it may not be elegant- it is a solution. I just have one question- I really want to make this a library that has multiple uses outside of my game, so I would really like to make collision detection dynamic. Do you think that I should just make an array of SDL_rects, surfaces, etc and each new sprite I make just increment the variable and store which array number that object is inside of it’s class- or should I have an external program to take care of that and just log all of the surfaces, etc outside of the class structure? (sorry if that wasn’t clear =/)

In response to the links on lazyfoo- honestly that’s where it all started, with an impressive set of tutorials and a little bit of drive on my part =)

As far as the existing sprite libraries- Well I was honestly being rebellious. I wanted to write my own code, reinvent the wheel if you will. But I think I have come up with something that suits me better- and though it may not make sense to someone outside the convolution of my brain- it does in fact click with me.

Hah, sorry for my long-windedness- it may have been so, but I felt obligated to answer at least a few questions…

I hope to implement this in the next couple of days, and if you would like me to I can post some code- really the biggest thing I have worked on so far is the sprites- but the collision detection has eluded my grasp for a slight intermission and has really slowed my enthusiasm. But with renewed vigor I set out in my quest to make the ultimate sidescroller with imperfect physics and horrible graphics!------------------------
#include <sig>

using ultifinitus::signiture;

int main(int argc, char* argv[]){
sigout << coolest signature ever;
}

ultifinitus wrote:

#include

using ultifinitus::signiture;

int main(int argc, char* argv[]){
sigout << coolest signature ever;
}

LOL [Laughing]------------------------
http://mandarx.xoom.it/index.php?lang=eng

Sounds really ambitious. You sure know how sell it, don’t you.

Imperfect physics or not, you can always make your graphics look
better with some creativity and photoshop. In fact, maybe that’s your
whole problem. You don’t make graphics that are easy to code with. No
uniformity, chaos. Unknown palettes. Unknown sizes.

But with renewed vigor IOn Wed, Mar 3, 2010 at 1:51 AM, ultifinitus wrote:

set out in my quest to make the ultimate sidescroller with imperfect physics
and horrible graphics!


#include

using ultifinitus::signiture;

int main(int argc, char* argv[]){
sigout << coolest signature ever;
}


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Well I suppose I could work on my marketing skills a bit =)

[Image: http://i842.photobucket.com/albums/zz344/spy4hearts/ninja.jpg ]

This is the running animation, what do you think?

I’m still working on collision detection!------------------------
#include <sig>

using ultifinitus::signiture;

int main(int argc, char* argv[]){
sigout << coolest signature ever;
}