2D sidescrollers and collision detection

I haven't really learned about graphics and C++ yet, so bare with me here. For anyone who has made a sidescroller before: I just was really curious about collision detection. How does it work? I remember when I was trying to make a game a long time ago in Qbasic...lol. I must of had a hundred of statements that looked like this (i forgot all the syntax in basic, so here it is in C++ form):

Code:

---

if (x > 10 && x < 20 && y > 5 && y < 90)
{
    if (x < xtemp)
    {
        x--;
    }
    else
    {
        x++;
    }
}

if (x > 7 && x > 18 &&....)

---

Since that's so tedious, can someone explain how else you would do it?

You could do this a few ways..

a) Rectangle based collision: each object has a rectangle associated with it, and you check if the rectangles are colliding using pretty simple math.
b) Array based collision: you keep an array of where walls & obstacles are, then you can easily check the parts of the 2D array against where the player is. Works best for tile based games, but could work for others.
c) Item by item collision, similar to rectangle based except you'd use shapes more exact than rectangles on non-rectangular objects. More precise but hardest to do.

Hmm...rectangle based collision seems intresting. Say X is my main character and I want to check to see if he's touching the square:

||||||||||||||
|||||||||||||| X
||||||||||||||


If the character can move up, down, left and right then there would be 4 sides that he can touch the square. Are you saying I can do one simple check to see if X is touching it?

Yes, if you organize your code so that everything has a rectangle that it's inside you could test your scenario in one check.

Is that a common approach?

Using rectangle for enemies is rather common, for a level I'd design a "map" format that'd look like this.

Code:

---

o    XXX  X
XXXXXXXXX  X
XXXXXXXXX  XX

---

o = the player
X = the level itself (the static parts of the level)

you could store that level as:

222223332031

which is the heights of the blocks.. assuming all blocks have a given size that format is best and doing collision against it would be making sure that the playerY > posHeight*blockHeight

X collision is similar but a little more compilcated. If you have more irregularly shaped terrain rectangles or polygon collision may be better.

Looking at that diagram gave me inspiration to make a sidescroller text game, YAY!

^I've tried, it's too hard.

I know, I just found out.

Quote:

---

I've tried, it's too hard.

---

No, it's not; you just have to take time and work yourself up to that experience level by doing simpler programs/games first. :)

I think he means that it's just easier to do it with an API, text is kind of limiting.

Well, the same basic idea is applied in a sidescroller with text graphics as in a sidescroller with real graphics, except that the drawing primitives are different, nothing changes all that much.

Quote:

---

Originally posted by TechWins
nothing changes all that much.

---

Yes it does. Well, I can't really say for sure becasue I haven't had much experince with graphics yet, but I know there are probably alot more challenges becasue of the limitations. For instance, just to make the letter "X" move on the screen with user input you have to think in terms of text appearing on the screen as you move down the screen, so you need one huge loop that will about a whole bunch of spaces and when x and y is equal to x and y of the character in the loop, that's where you output "X". So actually, your thinking process changes alot. BTW this is for console app.

Once you get the hang of it, it's actually easier to use graphics then to have to finagle (spelling?) with text. And you'll be much happier with your projects as well :D. If you're a bad artist, don't worry. You can download free domain artwork or make your own "programmer-art" (a term used when the programmer rushes a bunch of art just for testing :D). I usually make programmer-art.

funkydude, that applies to the drawing routines ('drawing primitives"). The same concept will still apply except to display the map/grid/whatever to the screen you will have to take a slightly different method. All in all, it is still the same, except the different approach you take in displaying everything.

I'm saying stuff like, you can't only move the character up partially, it has to go up a full line, so there isn't the ability for much physhics and such.

you can have the same realistic physics as graphics. Gravity is gravity. Momentum is momentum. Do you see anything in Newton's laws about graphics? :p