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?

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

Unless you're planning on using non-right-angles for anything other than ramps... which I am. Also, nice oxymoron. ;)

EDIT: I see what you mean, definitely less trig involved, even for my above statement. I'll convert all my classes, and tell you how it turns out.
EDIT 2: Okay, how the heck to I program bouncing now? XD

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.

I'm using an effective AABB for my object. I'm currently attempting to bounce it off the walls of the window (drawing using BufferedImage - it's in Java).

Using my own motion system class, I have the program set up so that every tick (about 1/60 of a second, not the same as a frame) the object moves in relation to its current acceleration and velocity to its new position. Both velocity and acceleration are vectors (a custom class), and x and y are held as doubles for precision.

I then check for whether the AABB is outside of the bounds of the window.

The problem is somewhere in the collision position correction section, which I'm still telling you is the problem. My first go was something like "If the x-val of the AABB is out of bounds, move it so that the x-val is back in bounds; repeat for y."

Then I used the bounce function.

This obviously causes, as I've stated, the infinite bouncing problem (it also doesn't play nice with a "bounce" with restitution of 0). The problem is how I correct the position, and I have an idea of how to fix it: I can check for whether the next movewill put me out of bounds, if so how far; then using this, back up a specific amount so that the intersection amount becomes 0. I'm having troubles coding specifically this.

Sorry if that sounded impatient, it's just that it's very difficult to explain it when I don't have the code to put up atm.

Yes, I realize this; what I've been trying to say is that I can't figure out how to correct the collision so that it is precisely set back to where the object is just barely touching the wall.

When I tried to correct it by simply placing it back into the bounds, it created the effect of an infinitely bouncing ball when its bounce height got small-ish. It never - literally, never - stopped bouncing.

So yes; How do I correctly, err... correct the collision?

No, it's nothing with the actual bouncing; it's a problem with collision detection. I can't figure out how to bounce precisely when the object hits a wall.

Also, I could show you my code, but it may get a little confusing as I've already got a lot of stuff set up in separate classes. Really, all I need is a good collision detection algorithm that's precise.

Honestly, I can't help you with your application, but I can tell you how the simple calculus works (which I'm assuming is what Alvaro is referring to).

To give an extremely simple introduction, a derivative is the instantaneous rate of change at a specific point on a line. The derivative of a function f(x) (which is notated f'(x)) is found by using the difference quotient:

(This picture's from the Wikipedia article on derivatives; just replace a with x.)

So if f(x) = x^{2}, f'(x) = {the limit as h approaches 0 of} ([x+h]^{2} - x^{2})/h. This may seem like it would equal 0; however, if the h variable is left in during expansion, you get:

{the limit as h approaches 0 of}(x^{2} + 2xh + h^{2} - x^{2})/h --> {the limit as h approaches 0 of}(2xh + h^{2})/h --> {the limit as h approaches 0 of} 2x + h = 2x.

Therefore, the derivative of x^{2} is equal to 2x.

There are a lot of rules for derivatives that make derivation a lot easier, e.g. the power rule. This states that the derivative of a polynomial function's derivative can be found by taking each term, multiplying it by its power, and then reducing the power by 1. Thus the derivative of x^{3} = 3x^{2}, and the derivative of 2x^{2} + 3x = 4x + 3, etc.

Now, for Alvaro's function, (1+e^{-x})^{-1}, there are a few other rules involved; its derivative (I'm pretty sure) is -(1+e^{-x})^{-2}-e^{-x}.

My difficulty wasn't in finding the normal of the slope, I can do that in my sleep - my problem was apparently failing to know what a dot product was. Heh...

Thanks for the equation - maybe it'll also fix the bug I'm having with my bounce equation (a ball with a restitution of 0.95 fails to decrease bouncing height enough to where I can safely stop it without having to wait for-freaking-ever).

EDIT: I got the equation working, but my bounce bug still remains, but it now applies to sliding as well (Hurray, moths in the machine). Basically what's happening is that no matter what restitution value (between 0 & 1, obviously) I give the object, it simply keeps bouncing. For ever. And never stops. So should I apply a friction force as well? (I think what's happening is that, since the amount the object bounces is (restitution)^(num of bounces), it simply begins to level out and become more difficult to bounce noticeably less.)

@EpiC Nostalgia:
I do have a design document, but I think I go into too much detail for people that just want to see the general idea. However, I do see your point. Yes, I'm still designing, and no, I'm not going to just go in fingers blazing. I've taken quite a bit of time taking big parts, and chopping them into smaller problems (like the land generation for example). I've thought about how I want to go about programming each thing, but that would have taken too long (to write AND to read) here.

I can still post it somewhere though, if you want.