OpenGL is a 3D API. It can be compared to Direct3D, which is
part of DirectX. As you know, Direct3D is only available on Windows (and, well, X-box), but OpenGL is available just about everywhere you can have 3D acceleration and even many places you can't. So, using OpenGL for 3D acceleration is much more portable.
For 2D, we've got things like SDL (what DROD uses). SDL is a thin wrapper over system-specific stuff like DirectX, Xorg, OS X, etc*, so DROD doesn't have to worry about all those little details that change for every system and just concentrate on the
game in stead. Which is nice. SDL does a lot more than just 2D, though. It can be seen as a cross-platform alternative to DirectX. For 3D, SDL supports setting up an OpenGL window/context and leaves it at that. Then you just use OpenGL in the usual way.
So anyway, once upon a time there was 2D acceleration. Then 3D came along, and little by little 3D acceleration was all that graphics card and driver manufacturers cared about. Oh sure, you can still get some 2D acceleration in Windows via DirectX (using obsolete APIs), but using OpenGL or Direct3D to do the same thing is much faster (assuming you do things right, that is). And us poor Linux people using XFree86 and Xorg don't get any 2D hardware acceleration at all. Or, well, there's XRender, but if that's accelerated it usually uses 3D acceleration in the backend. SDL doesn't support XRender, so if you use SDL it's a moot point anyway. (And then there's things like XGL, but that obviously uses OpenGL too.)
So! If you want fast 2D, you use a 3D API. Preferably OpenGL, since it's more portable, but if you don't care about portability Direct3D should work as well.
However, one thing to keep in mind is that using a 3D API to accelerate 2D if you
don't have 3D acceleration will result in a
major slowdown. 3D APIs are meant to be fast at rendering 3D stuff, so they're designed to be good at that. But doing fast software 3D is different from doing fast software 2D. So, hardware 2D-on-3D is much faster than software 2D, but software 2D is much faster than software 2D-on-3D!
So you have to make a choice. Do you want your game to run faster on current hardware but be unplayable on old hardware, or do you prefer to have it run slower on current hardware but at least be playable on older hardware as well ? Speed or compatibility ? You can of course do both; support acceleration, but support software rendering as well. That means having multiple graphics backends, though, which is much more work than just supporting one.
Unless, of course, you're using a wrapper that handles all that for you. Does SDL do this ? Well, no, SDL 1.2 does not. But the next major release of SDL, which is currently in the works, does! SDL 1.3 has a redesigned API that can take advantage of 3D acceleration for 2D operations.
Does this mean that DROD can automatically take advantage of this once SDL 1.3 is out ? Well, no. As I mentioned above, SDL 1.3 has a redesigned API, so it's not as simple as just lobbing out the old SDL and plopping in the new one and hey presto, magic acceleration. DROD would have to be ported to the new SDL. That in itself would not be enough, though. DROD would also need to be redesigned in places to be more acceleration-friendly. Direct pixel manipulation of hardware surfaces is a big no-no when you're trying to accelerate, for example. You can do it, but it's very slow. Slow enough that you can end up losing whatever speed advantage you got by switching to acceleration in the first place. You can get around that by using software surfaces, but those obviously aren't accelerated.
So, er. Does that answer your question ?
~ Gerry
* It even supports some stuff without an X in its name!