I fear I won’t be able to offer much of an answer here, but it’d help if this issue could be cleared up once and for all.
Most threads discussing this end openly and without any true result. I simply fail to imagine big projects would not use 2D portions.
On a sidenote, right after DOS I started out with DirectX and - at least then - DirectDraw didn’t get you very far on 2D coding either. It could move a sprite across the screen, but that was it. Framerate dropped below zero for any of the serious pixel-per-pixel effects I was attempting to do.
But anyways, I’d just like to summerise things a little.
The pure opengl solution to 2D programming appears simple: We just use glOrtho to get an orthogonal space (which means your scene won’t show perspective) and we draw everything on a plane floating before the user’s eye.
Practicly, this would translate to using glVertex2i and getting it over with, but this is generally a performance hog and considered a bad idea. Basicly the engine sees them as cornerpoints in 3d as opposed to the 2D pixels you give them credit for.
But wait, opengl features a solution for this: glDrawpixels. Actually this was quite a joke, I tried it on a voodoo bansjee and just yesterday on a TNT2M64 - I thought the program had crashed. Actually it simply needed over a second to refresh the (entire!) screen.
So we’ll head on to the next and most accepted and fast solution: a texture. Simply create an array with all your data and paste it on a plane which you place right in front of the camera. This appears the same as the first method but now you only set 4 vertices and just paste everything on the figure. Furthermore it is my understanding most cards accerlerate this in some manner. But alas there is 3dfx who implied a 256x256 texture limit. So eventually you’ll be forced to - indeed - break down your screen into a multitude of texture maps and get busy deciding what points go where. Result: in fullscreen operations you produce way too much overheath.
Actually one of the most usefull suggestions appeared simply not to use opengl for 2D at all. OpenGL is a 3D engine while these cases would basicly require just fast, direct screen buffer access.
A few days ago I picked up SDL which is a platform independant library somewhat similar to glut. It can sit in between opengl and the screen as an interface and provides you with /direct/ screen access. In addition it also features some lowlevel stepups to input, events and audio.
Unfortunately - though I haven’t figured out everything yet - this direct screen access becomes void once you startup opengl :/… It appears they are working on it though, but for the moment you appearently can only blit rectangles onto an opengl drawn screen.
There, I doubt this answered anything but hopefully one of the allmighty gurus will pick this up and put the issue out of the way
P.S. I am really a very wacko amateur to OpenGL, do not trust me .