There are no real sprites in SDL. As it’s a cross-platform library and sprites are heavily hardware-dependent, there’s no easy way to work them in. You could try to take advantage of a platform’s hardware by intercepting attempts at creating SDL surfaces and seeing if its properties fit within a hardware sprite, but it’d be tricky to make something like that work with existing code. Everything is done with bobs instead.
Anyway, that’s academic, as - from what I’ve seen so far - the GP2x doesn’t have sprites either.
Getting sprites working in SDL is pretty easy. Load a bitmap, convert it to a surface that matches the current display, then blit it out. It even supports a transparent value, so empty regions of a bitmap won’t be rendered to the display. I’ve built a Sprite class that does all of that business that inherits from a simplistic SpriteBase class.
As some of the sprites are animated (SAM and UFO at the moment), I’ve stolen the Animation class from Woopsi and re-jigged it to work with SDL’s types and surfaces instead of u16 bitmaps. I’ll integrate it into an AnimSprite class, which will inherit from the SpriteBase class.
I spent some time getting SVN working on my Linux box before starting coding today. I’ve got the SVN VMWare appliance created by Young Technologies installed. Getting it working was more fiddly than I’d hoped - authorisation seems to be broken (or there’s something cryptic in the config files I’ve missed) and the WebSVN install doesn’t seem to work properly (or, again, there’s a config problem somewhere). In any case, I don’t need authorisation and don’t care about the web interface. It gives me a source control solution, which is all I want. It’s separate from the underlying hardware and OS install as it’s a VM, so I can easily move it to another machine and back it up as needed. The code for ChromaX now lives in SVN.