Okay so I've never done that before, but I gave it a quick think and that's what I thought of.

Let's say you have a curved surface sprite that is 16 pixels wide. Let's make it look like this :



Now you have to build a 16-entries normal angles table. By that I mean a table that will hold 16 values, one for each X coordinate on the sprite, and which will represent the normal angle of the pixel on that coordinate. I don't think you have to calculate them, just guess them based on what you see. Of course, they had to be in the range 0-255 and not 0-359.



Using these angles requires all of your velocities to use polar coordinates. That means that your ball will not have X, Y, VX and VY coordinates (VX and VY being velocity amount for X and Y coordinates), but X, Y, VR and VT coordinates. X and Y will be your ball's coordinates on the screen, like you always used them, but VR and VT will be the polar coordinate for your velocity vector - respectively the length and the angle.

When you hit a pixel - I'll let collisions to you - just grab the X coordinate of the pixel relative to the start of the sprite, get the corresponding angle in the normal angles table and apply symmetry with the velocity angle - I think you'd do velocityAngle += (pixelNormal - velocityAngle) * 2. Then that should be good.

Of course you will have to write the code to handle polar velocity. You might want to apply trig on the angle and multiply the result by the length, to add both results (X and Y) to the ball's coordinates.

The curved surface is moving at a static speed, right? If you treat the collision like a static collision, but apply the curved surface's velocity as an offset to the ball's velocity, then subtract that offset from the result, you get the correct result.

Left and right, it will be constant. I'll make the curved object bounce on command, though.

Okay so I've never done that before, but I gave it a quick think and that's what I thought of.

Let's say you have a curved surface sprite that is 16 pixels wide. Let's make it look like this :



Now you have to build a 16-entries normal angles table. By that I mean a table that will hold 16 values, one for each X coordinate on the sprite, and which will represent the normal angle of the pixel on that coordinate. I don't think you have to calculate them, just guess them based on what you see. Of course, they had to be in the range 0-255 and not 0-359.



Using these angles requires all of your velocities to use polar coordinates. That means that your ball will not have X, Y, VX and VY coordinates (VX and VY being velocity amount for X and Y coordinates), but X, Y, VR and VT coordinates. X and Y will be your ball's coordinates on the screen, like you always used them, but VR and VT will be the polar coordinate for your velocity vector - respectively the length and the angle.

When you hit a pixel - I'll let collisions to you - just grab the X coordinate of the pixel relative to the start of the sprite, get the corresponding angle in the normal angles table and apply symmetry with the velocity angle - I think you'd do velocityAngle += (pixelNormal - velocityAngle) * 2. Then that should be good.

Of course you will have to write the code to handle polar velocity. You might want to apply trig on the angle and multiply the result by the length, to add both results (X and Y) to the ball's coordinates.

...I'm assuming this works with falling with proper accel, right?

Well yes, you'll have to handle that. It's pretty easy as soon as you're familiar with binary trigonometry.

I am not.

Oh ... well I don't know your age, but there are many things you can't do if you don't know trig. Including this. And sorry but I don't feel like doing the work of your future math teacher ; trigonometry is something complicated and I don't know your grade (don't really know how to say it, the year you're in I guess).