Okay, so I came up with this formula for finding the precise moment of impact.
t = the amount of time one discreet timestep takes (currently set at 1/60 of a second)
mv = magnitude of the velocity vector (x & y change each stimestep by t*velocity, with respect to each axis)
p = the amount the moving object penetrated past the collision point as measured by the wall's normal (0 if it didn't collide)
?v = angle of the velocity vector
?w = the angle of the wall

The amount of time the object should move is equal to t - (|p/sin(?v-?w)|/mv). Then it bounces, and runs the rest of the timestep. I'm almost certain this is correct, right?

Well, I'm getting a bug where when it corrects, the object bounces, but flies off the screen when the bounce height gets near 0. Within a second, its coordinates are in the billions (bouncing off the walls of a 640*480-ish window - obviously a problem.) So, err..... Yeah. Any ideas?

Selenaut

I'm using angles because I'm using vectors and not keeping track of individual x- and y- axis motion, but rather speed in a direction. The use of angles also gives me the possibility of using angles other than right angles, e.g. 45- and 22.5-degree ramps. (I'm hoping to get to ramps in the future, but at the moment I'm only worrying about 90-degree angles; I'm just trying to write it so that it's easy to port later.)

EDIT: I forgot to mention the whole division thing: That's exactly what it is, and I can't believe I didn't realize that. I'll let you know if correcting that fixes the problem.

Thanks,

Selenaut

PS: I hate the quick edit feature. XD

What reason do you have to say that using x/y vectors would not permit you to have anything but right-angle ramps? Using angle/magnitude for vectors is almost NEVER the good way of doing things, it quite simply makes everything more complicated.

Using angle/magnitude for vectors is almost NEVER the good way of doing things, it quite simply makes everything more complicated.

It is not that there is less trig involved when using x-y vectors, but that there is NO trig involved.

I already showed you earlier how to do bouncing.

That you say you have done bouncing, but cannot figure out this, plus that you talk about the 'angle' of the slope tells me you are using trigonometry to do the bouncing... *sigh*

The solution is incredibly simple, using simple vector operations.

You have the slope normal vector (As opposed to its angle)
You have the incident velocity.

The outgoing velocity is then: newVelocity = velocity - normal*(1+e)*dot(velocity, normal)
where e is the coefficient of restitution. For a perfectly elastic bounce e = 1, for a perfectly inelastic bounce (your 'slide') e = 0.

If you're struggling to compute the normal vector. Assuming you have two positions for the slope 'a' and 'b' that you're using to compute your angle like atan2(b.y-a.y, b.x-a.x), then the normal for this slope is instead: unit(a.y-b.y, b.x-a.x). The normal is a unit-length vector that points 'out' (or 'in' for these purposes, makes no difference to the result) of the surface, so the left side of a box will have normal (-1, 0) etc.

Are you saying that I can just use the x- and y-components to do the same thing? I figured it out but had to use a bit of trig... and the original method. XD

EDIT: ...Why the heck do I have like 7 -1's on this thread alone? (Not to mention they're my only -1's.) How am I supposed to report this?

Alright, shy of some bugs that I can fix relatively quickly (hopefully), I got it working. Thanks guys.

Selenaut

P.S.: Can anybody tell me why I have so many -1's?