Great responses!

So, I'm thinking I'll stick with the one big texture full of tiles.

As for a solution to the rotating, scaling without bleeding... I do remember having this problem in earlier tests, and I was getting around it by leaving space around each tile.

I'm thinking of other ways to deal with this as well. If I have only a few objects in the game that need to rotate/scale I can either use a seperate texture for each of these special objects OR use a seperate texture to copy each of the frames into JUST before displaying it... I'm not sure how to do this right without make the evil Memory->VRAM copy.

The extra screen buffer is very intriguing to me as there are many effects possible with this that excite me, but I'm wary of doing it using SDL for cross platform. It seems unlikely that I'll be able to get this to work nicely on multiple systems (Windows, Linux, etc.)

I mean, I know I could get it to "work", just not with any usable performance.

Anybody spot any flawed reasoning here? Any other methods people are using?

Just rotate the quad you draw the tile on if you want to rotate the tile. No copying involved...

That's how I currently do it, and because of the previously discussed filtering it bleeds in from the neighboring parts of the texture.
The extra-border-around-the-sections solution rubs against my artistic nature.
Plus, when I've done it in the past, a one pixel border was not always enough... this is just a waste of precious VRAM in my opinion. However, I realize it might be the best compromise.

I was looking for a possible way to avoid the bleeding without adding extra hack work to the initial tile creation.

Aaron

Well then, just use one texture per tile. But don't say I didn't warn ya