hi.

Hello,

My opinion, not enough info provided for help. Obviously a bouncing ball will loose some of its height value as it bounces, and assuming from your brief code snip, you are also using angles for the ball collision against....what the viewport? As far as "bouncability," I suppose you are referring to different properties of say bouncability of a brick vs. a tennis ball? I think more info is needed to correctly provide adequate guidance, again my opinion.

probably forgot to mention it, even if I set the boucability to 1.0f (or if I remove this part of the code) it still happens.

It is generally the case that a first-order integrator (like in the code) will lose or gain energy over time. That's an unavoidable effect of the simple discrete integration. If you want perfect harmonic motion, you need to use a higher-order integrator, like Runge-Kutta-4. Note that with RK4, you also need to be able to come up with the proper derivatives for three points in time during the timestep, not just one; that makes collision detection a lot harder!
Try this: If you set "bouncability" (also known as "restitution" in physics circles) to 1.1, your ball should gain energy with each bounce. If it doesn't, then you're doing something else wrong, like calling movement more often than integration, or something like that.

The ball might be getting stuck to the floor because hitWall reverses the ball velocity whenever the ball is out of bounds, even if it was out of bounds in the previous time tick.  If the ball doesn't bounce all the way back into the viewport in one time tick, hitWall could reverse direction again, pushing the ball farther out of bounds.

Maybe hitWall could only reverse direction if the ball is out of bounds and if the current velocity is carrying it farther out of bounds.  If the ball is out of bounds, but is heading back in bounds, there's no need to reverse the velocity.

Going to a higher order Runge-Kutta simulation is the best way to get more accurate motion, but swapping the position update and call to hitWall might help some.  Right now, the code updates velocity, updates position, then updates velocity again.  It would be cleaner to do both velocity updates before the position update.