I think the general idea is loop through each source pixel and multiply the pixel position by a rotation matrix.
Rotation is relative to the origin, so you have to subtract each pixel by the center of the image before you multiply by the rotation matrix.

Here some code i wrote to rotate images in visual basic.
[source lang="vb"]Public Sub rotate(source As PictureBox, dest As PictureBox, ByVal deg As Single)
'i guess you could think of the PictureBox as SDL_surface
Dim cpex As Long
Dim cpey As Long
Dim cpeColor As Long
Dim tx As Double
Dim ty As Double
Dim tpx As Double
Dim tpy As Double
Dim Icos As Double
Dim Isin As Double
Dim sw As Double
Dim sh As Double
Dim rad As Double
Dim cx As Double
Dim cy As Double

sw = source.Width
sh = source.Height
rad = deg * (PI / 180) 'convert degrees to radians
Icos = Cos(rad)
Isin = Sin(rad)
cx = sw / 2 'compute center of the image
cy = sh / 2 'compute center of the image

dest.Cls 'this clears the destination "Surface"

'C.P.E ->current picture element
For cpey = 0 To source.Height - 5
For cpex = 0 To source.Width - 5
cpeColor = GetPixel(source.hdc, cpex, cpey)
tx = cpex - cx
ty = cpey - cy
tpx = ((Icos * tx) - (Isin * ty))
tpy = ((Isin * tx) + (Icos * ty))
dest.PSet (tpx + cx, tpy + cy), cpeColor
Next cpex
Next cpey
End Sub[/source]

could you explain that abit more? if possible?

What specifically would you like me to explain?
The math behind the rotation?
Or the Code i posted?

So any ideas on how I could do image rotation and image flipping with SDL?

Keep in mind that the default renderer in SDL is a software-based one, and therefore anything manipulating some sort of image is done by the CPU on a per-pixel basis. That being said, transforming an image will require you to do some work, as SDL does not provide this functionality out of the box. If the transformations are simple, such as rotating by multiples of 90 degrees, or flipping an image, then it's a matter of the order in which you write the pixels of the source image to the destination image. If the transformations are complex, then you enter a world of hurt* because you need to decide how to iterate over the destination pixels or the source pixels (using the minimal number of reads/writes) such that there are no gaps or overlaps in the destination image.

Next, you get to decide* whether or not such expensive operations are affordable in your real-time rendering budget. Remember, this is software rendering: We need to consider the cache, among other things. Then you'll probably end up caching the transformed images before-hand and blitting them (fast!). Then you'll realize that's what SDL_gfx already does: Transform an image into a new image.

So, long story short, run with SDL_gfx; it'll hurt less than doing it yourself.

* I've done it before. It's not fun.

just wanted to ask if you think SFML would just be a better idea overall.

SFML is generally the better option. Out of the box SFML supports OpenGL rendering, TTF font rendering, and loading images of various formats. All of these things require an additional library with SDL (OpenGL32.lib, SDL_ttf.lib, and SDL_Image.lib, respectively).

I just wanted to point out that you really should learn how rotation matrixes work, if you haven't already. It's really handy to understand how they work (especially if you plan on moving to 3D in the future).