Re: SDL
I received a number of comments on my previous blog post. I was going to reply to each of them separately, but then decided that this was worthy of a blog post of its own.
Two people posted comments telling me to check whether I had OpenGL acceleration switched on.
In case you guys missed it, Freetennis is a sprite-based and essentially 2D game. It does not use OpenGL, by the looks of it. Neither does starfighter, powermanga, or a number of other 2D games I tried. Yet they all require the full 1.3Ghz of my processor, and some of them, including freetennis, think even that isn't enough.
I received some other claim that SDL by itself performs pretty well. While this may be true, the fact remains that many simple games that should work well on older hardware seem to require a lot of CPU time, and that they all seem to use SDL. If it's not SDL at fault, then it's probably the SDL documentation which doesn't stress the need to KISS enough. Or so.
A final remark compared the situation to Quake2 on his X40. I don't know what you've been doing, but I'd been happily playing Quake2 on my 650Mhz PentiumIII until that one got migrated to become my parent's computer. Without hardware acceleration. And, luckily, without SDL, too.
In case you missed it, many 2D games use OpenGL too, since it seems to be one of the faster ways to bring pixels to the screen today.
E.g. xmoto is entirely 2D, but needs OGL to run and is dead slow without HW acceleration.
OpenGL can, and is, used for 2D. In fact, 2D is just a specialized case of the 3D math in OpenGL. This is how XGL and AIGLX are able to do what they do. One game I've ITP'ed and will maintain upon its release is a 2D sprite-based game that uses OpenGL to render, and it's just one other example.
As to SDL, I have no idea how it works under the hood, but I've noticed the same effect. One issue may be simply a lack of optimization in how graphics are moved to the screen. Drawing a sprite is a pretty fast operation, it's how you put it on to the screen that's hard. In the old days, you would only copy certain portions of offscreen buffer to the screen memory, thus saving you lots of slow operations which were usually limited by bus speed. These days it seems like a lot of rendering operations are lazy and simply copy the whole offscreen buffer to video memory each time. You simply couldn't do this in the old days, but you can get away with it now, albeit at the cost you see. I don't know if this is the actual case, but the way that I've noticed the lag in some games that should be fast implies that this is may be what's going on.
Note that the X server is working around such problems by using Composite and a compositing manager to provide more intelligent ways to draw and re-draw objects on screen. This is finally coming of age with XGL and AIGLX, and it's a hard problem which is why it's taken so long. This won't help games or anything, but it will significantly help when redrawing windows that get obscured for some reason.
In the old days (DOS/VGA) the offscreen buffer was in video memory and did not have to be copied at all
Also it is not even about laziness. If you have a scrolling 2D game, it has to copy the whole screen every frame.
And it should not even be a problem either, other platforms can handle it just fine. But plain X is just too slow for this kind of blitting. Just see what happens when you turn off the Xv support in any video player.
I haven't looked at much open source game code, but I suspect it's the opposite of keeping it simple.
A simple game will likely do something like this
while (true) { get_input(); update_state(); render(); }
This is a simple game loop, but when employed it will consume your entire CPU, possibly doing nothing if render() limits itself to a certain refresh speed. What's really needed is a good discussion about open source performance profiling with non-trivial examples. I think game programming is a subject that entices a lot of novice programmers, and SDL and such also lower the barriers to entry in certain ways that simultaneously allows more software and more software written by inexperienced people.
Maybe the best way to solve this is to pick a game, investigate and fix it, while documenting the process and including as many people as feasible. I agree that games that don't appear to be terribly stressed by CPU limitations shouldn't be consuming tons of it.