I've also realised that my "quick fix" for using OpenGL depth drawing isn't going to work with alpha blending. Obviously OpenGL can't know what depth each alpha fraction of colour that a blended pixel has is set at; it's just got a Z-order depth map (or at least that's what I think it's doing).
I suppose I'm just used to either treating software packages as black boxes or coding things up myself; OpenGL is somewhere in-between. I guess if I want to make a good 2D engine that has the feature I want, is easy to use and has reasonable performace I'm going to have to learn a bit more about engine design and OpenGL. So I'll have to hit the books, do a few tests, ask a few questions on the forums and write a few design documents.
However all that has to wait until after I've got some more game experience. My present plan was to make a slightly hacked together graphics system for Ice Slider, then iron out the creases with a few revisions. But given I'm stumped on the best way of approaching the graphics pipeline or rendering order or whatever-you-call-it I'm debating returning to the good old fashioned technique of "total hackery". Thinking it through I'm probably going to have to move some of the rendering decisions into the game logic itself purely to get sensible performance. However I'm still undecided on whether I should put wrapper functions around all OpenGL calls in the name of reducing coupling with hardware dependant systems. Accursed software engineering!
All this being written, I think I'll need to distance myself from graphics coding for a little while while my brain mulls things over and I read up a bit more on this to make a decision; maybe post a few forum questions. Guess I should move to doing some test art so I know what I need to code. Plus I code up the input module. I'll move back to the graphics on the weekend.
And that's my "forget about the low-level crud, I just want to see your cool game in action!" for the day. [smile]