Sure. You can do collision detection with rotated sprites, or pretty much any polygon (as long as the shape ain't terribly funky). There's a math formula for determining if two lines cross, and you can check if a point from one polygon falls inside the other. A math whiz will be by shortly to spell it out (I sure can't) ....

I guess I could step in being a "math wiz"... err sorta. I could figure it out. Actually most math problems like that are easy to solve if you have the motivation and the time to just get your hands dirty on it.

I'm pretty sure I'm right here, but if you want to do collsion detection, of any sort, there is no "equation" or more precisely the relation you are looking for is =. Looking for > and < will collision detect as partitions.

As you all probably know, the equation for a line is y = mx + b where m is the slope and b is the offset on the y axis.

If you want to know where two lines meet, set them equal and solve the equation. If there is no solution, then the lines are parallel and not overlapping. If the solution is a simple identity ( 0=0 ) then the line collides at all points, and therefore it is the same line. If the lines are not parallel then there exists one solution to the problem.

Find this solution, and then check the solution to see if the point falls between the boundaries on both of your line segments. If and only if both line segments contain the point there is a collision with two arbirary line segments.

This same concepts applies to any linear function in any number of dimensions. Maybe I can come up with an example. How about a line segment from (1,1) to (2,2), and one from (3,0) to (0,3). The equations are:

y = 1*x + 0
y = -1*x + 3

Now to solve (by subsitution of y with x):

1*x + 0 = -1*x + 3
      x = -x + 3
     2x = 3
      x = 3/2 = 1.5

Now to solve for y, now that we know x:

y = 3/2
y = -3/2 + 3 = 3/2

If you notice you get the same y value for each. This should always be the case, or something went wrong. Now you know the point of intersection is (1.5, 1.5), which is the correct answer if you draw the segments and look at them.

Now all you have to do is test to see if (1.5, 1.5) is in your line segments which you can do with simple if tests ( is 1.5 < xmax and is 1.5 > xmin ) for both lines and also for y.

Wow that was fun. I wasn't expecting to go that far with it. And I do think I solved the problem adequately enough to prove my point.

I didn't cover how to make the equations for the lines, which is pretty easy. Also note you can easily find the angle (and a quick test for parallelism) by applying the dot product to the equivalent vectors, for which the angle may be useful in the physics of the collision (you should know the speeds from your engine already).

This is for line segment collision though. Note that checking for collisions of lines will NOT check for collision in bounding boxes, if one box is entirely inside the other (which is always possible unless all boxes are of the identical width and height).

Tron Boy: You don't need C++ (Makes it easier though). You need maths/physics vectors which means a measurement that defines both direction and magnitude.

eg.

typedef struct {
    float    x;
    float    y;
} vector_t;

or

typedef struct {
    float    angle;
    float    length;
} vector_t;

A C++ vector is just a self adapting array (I think).

What do you want to collide against the diagonal line? Circles and Spheres are easier, just check the distance to the line. If the circle is 4 units away and has a radius of 5 then it is intersecting.

Here is an unoptimised example from a Line class I made ages ago.

If you want that suoer mario 3 effect, that's really easy.
What you do is soemthing like this:
You check if the player is on a slope (if the tile is a sloped tile). Then you adjust the y position of the sprite based on the offset inside the tile. Since you'll have 45 degree angles, that's pretty easy (the offset into the tile is also the offset in y direction),

Now adjust the speed of the sprite based on the slope (or simply adjust the position; this will be more easy but also less clean - but it'll work, so it's worth a try).

If you want to support slopes in a more general way, you can define offset arrays for your tiles which store the y-offset based on the x-offset into the tile. That way you can do curved tiles (like the hills in Ghost and Goblins).

I wish some one would spell out the math and such. I went with bitmasks for a reason; this stuff went over my head ...

I have tried it. And I keep all the articles I like on my hard drive and shortcuts to all the good threads.

Bitmasks are still easier