So 45 degrees points toward the bottom-right corner of the screen?

damn, all this time i based the angle from cartesian plane, i didnt know 45 degrees would be in bottom-right i thought it was upper right. but i guess its still the same

The unit circle assumes upward Y. If Y is downward you have to flip the circle over so that +X and +Y are in the right directions.

I'm not going to look at (or run) external code due to a lack of interest.

i mean play the ponggame.org, you can see there wht im trying to achieve

This didn't help me. I don't have the patience to sit here and play a Pong clone long enough to dissect the paddle reactions during gameplay. If you would explain exactly what you want to happen it would probably help both of us.

What if the ball hits the paddle and is deflected, but then is still in collision with the paddle on the next frame?

i already experienced this many times in this pong game, thats why the reflection logic and pongball.move() are on the same function so it can avoid that from happening

What? Anyway, correcting the problem would be better than working around it.

Negating the angle makes no kind of sense

like i said i based it from ponggame.org when i was playing it i realized when the ball hits the lower part of player1's paddle at angle 91-269 its just negated it, same with player2 paddle

Negating the angle is going to flip vertically. Think about 45 degrees vs -45 degrees.

speed and not angle speed{x,y}

what do you mean about this? my speed vector is just the speed of the ball. actually im using a vector with only x and y and operators overloaded with it

Vector representations:

struct Vector2D { float angle; float length; }; //or struct Vector2D { float x, y; }; //NOT struct Vector2D { float angle; float x, y; };

Consider this:

speed.x * cos(angle*Ball::pi/180)*delta

First off, you're not altering speed.x anywhere. You're not using the magnitude of speed, but only the magnitude of the x speed. cos() is going to give you the X side of your x:y ratio for the angle you feed it. sin() will give you the Y side. Those both need to be scaled by the same number (the magnitude or "speed") in order to make sense. {cos(angle), sin(angle)} will give a normalized (length of 1) direction vector {x,y}. You multiply that vector by the speed to get the scaled {x,y} that represents the actual velocity. You then multiply that by the time delta to get the displacement vector for that frame. (or you can multiply it by the speed before doing the vector math)

Can you explain what you want to have happen when it hits the paddle?

my function is doing fine, but i still dont have the logic when it hits the middle and the edges of the paddle.

but it looks like im doing it very wrong, can you tell me a more standard way of doing this pong game?

you know im really really newbie in game dev. as you see my class design is bad too(but nvm that)

The simplest way to do it is to use an x,y vector and just negate x when it touches a paddle && is moving toward that paddle's side of the board. (And negate y when it hits a wall.)

I think you're wanting to do some deflection based on what part of the paddle it hits though, so that won't work here. I still want you to describe exactly what kind of reactions you want. You have some kind of input-process-output in mind, but it's not clear to me and I think it's not fully clear to you. Draw me a picture and explain the input and output it in detail and I think the process will become obvious.

If not then it will at least provide a clear vocabulary for discussing the specifics of the problem.

can we do it while avoiding trigo?

The alternative is changing the behavior to not use any angles (as described above), but I don't think that's what you're asking for. That system can be tweaked a little bit based on other factors, but I really want to know what the target behavior is first.