An old question, but I had the same one. Let me tackle the parts that went unanswered.
"Is there a way to do anti-alias without OpenGL (such as modifying the graphics before hand, or possibly some function that I didn't find)? If not, how hard is it to convert a game written in SDL to use OpenGL as well (I have not worked with OpenGL before...)"
1) I like the OpenGL and SDL tutorials at
http://lazyfoo.net/
Step-by-step, including setup of the code environment and libraries, focused on game programming. More experience with libraries should clear up the second half of this question.
2) I think people answered a slightly different question than you asked.
With fonts, SDL creates Surfaces with antialiased edges. The AA is static, but the result is not (1 XOR 0) like ColorKey.
It sounds to me like you just want the same thing with images.
If this was your question, then of course you can do antialiasing in SDL. You can store whatever you want in the alpha channel (game designers do). You can make a new channel and append it to an image at runtime. It's just a bad idea to do this in SDL, that's all. To see why, let me make up an
EXAMPLE PROCEDURE:
to do it ourselves. Say we have an m x n image, with a white color key. We want to improve the color key filter used by SDL_DisplayFormat(). Create Jerome, an m x n array of floats. Where the image is white, set Jerome to 1. Leave all other other values at 0.
Say we stop here. An alpha of 0 is 100% transparent. So (1-Jerome) turns him into an alpha channel. For example, exit SDL, append (1-Jerome) as channel 4, save the image as a .png. Load it in SDL with SDL_DisplayFormatAlpha. The result should be the same as using a color key on the original image. Crummy filter, but fast.
Let's make it better. Take any white pixel, W, and dump some transparency on all eight sides. Add T% to adjacent pixels, and a smaller amount, t% to diagonal pixels, like this:
t T t
T W T
t T t
(the radius may be 2 or more pixels, or we can use another function altogether. Whatever we want).
Do this for all white pixels. For example, create a second array, Maxine, initialized to zeros. For each entry of "1" in Jerome, add the T's and t's to Maxine. Do as many pixels at once as you like. Then add Maxine to Jerome:
Jerome += Maxine;
clamped to 1. The only values of Jerome that have changed are '0's immediately adjacent to a '1'. They are now some value between 0 and 1, depending on how many of their neighbors were nonzero. Now (1-Jerome) gives us a (crudely) antialiased alpha channel.
There is a discussion at opengameart.org of some issues that might arise.
NOTES:
I)The filter can be made much more efficient. For example, we can detect, and throw out, zero terms of the sum, and collect additions by rewriting the sum (Convolution).
II) If we could give the transparency mask by a rule, we could work much more quickly. This is the case with fonts, which are defined by their edges. An arbitrary image has an arbitrary mask. Using the same techniques would be too slow. The reason SDL offers to perform AA on fonts turns out to be the same reason it *doesn'*t offer to do it with images. :)
III) There are an Awful Lot of pixels in an image, and all of this processing can be done in advance, with good filters, in an image editor.
IV) The filter can also be done with all pixels in parallel, taking the four channels as (simultaneous) vector components. (..so use the GPU)
To me, the last two points are the heart of the matter. SDL is a bad place to do it. If the border is static, then process it in advance. If the border is determined at runtime, it is prohibitively slow to do it anywhere but the GPU.
Hope that's useful! (and I'm always looking for corrections).
