Hi there.
I’ve been writing 3D landscape engines in OpenGL for sometime now.
However, I am wanting to write a game in OpenGL that will have menuscreens and information screens.
As I am developing for Win32, is it best to use GDI/DirectX (sorry, had to use the D word 
) or use glOrtho to set up a 2D area and use textured quads?
My main concern is that I will have to write routines to chop up large textures into small 256x256 tiles even for things like backgrounds.
Greetings,
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 
– Simkin.
P.S. I am really a very wacko amateur to OpenGL, do not trust me .
Regarding the generic OpenGL implementation, you can not use DirectDraw or GDI calls to draw 2D graphics in an OpenGL window if the window is double buffered. The GDI may be used if it is single buffered (and if the pixel format supports GDI). Accelerated implementations of OpenGL will likely behave differently from vendor to vendor. In general, mixing DirectDraw or GDI drawing with OpenGL is a big taboo. You should have no problem using OpenGL to render your 2D graphics. Just use a few textured quads and an orthognal projection. It really should not be that big of a performance hit if implemented correctly.
Just a quick question, because I think you may have stumpled upon a source of perpetual energy, or somesuch:
does a frame rate that drops BELOW zero mean the rendering is complete before the computation is already done?
cheers
John
Hehe, no I wish that were the case. I’d be a billionaire for sure. It just means my crude timer didn’t have adequate resolution to measure the time delta and so to prevent a divide by zero and to flag the failure of my timer, I forcibly set the FPS to -1.
I have since found that bug and fixed it. 
Originally posted by DFrey:
Regarding the generic OpenGL implementation, you can not use DirectDraw or GDI calls to draw 2D graphics in an OpenGL window if the window is double buffered.
I love when people say that you simply cannot do this. You can indeed use GDI calls in a double buffered environment, and I have. I forget how I did it, but I did.
Oh yeah, in a double buffered environment OpenGL always draws to the backbuffer. In ANY environment, GDI always draws to the frontbuffer. Thus, you draw your OpenGL first, call glFinish, then SwapBuffers, and then do your GDI calls. Trust me, it works.
The only drawback to this is that your GDI flickers because of the clearscreen via OpenGL and double buffering.
Kindof ironic, you think? GDI doesn’t flicker and OpenGL does in singlebuffering mode, and GDI does and OpenGL doesn’t in doublebuffering.
Anyways, its not “advisable” to use GDI for your 2D stuff cause of the flicker, plus GDI is relatively slow compared to OpenGL at that rate.
Siwko
Thanks for the replies!
With regard to DirectX, I was actually thinking of changing the display mode every time you had to use in infoscreen etc. which would have been longwinded to say the least.
Thanks again.
Hey Siwko, the reason I said that is because that is what Microsoft has written in their OpenGL documentation regarding the use of GDI and OpenGL. Not because I pulled it out of thin air.
Right, it’s true for the MS GDI Generic OpenGL Implementation (funny name, if it cannot use GDI commands in the window )
but the major hardware implementations should have no problems because this is something done in some CAD applications and therefore has to be supported to get certified.
You have to select a pixelformat which supports PFD_SUPPORT_GDI. Some implementations allow to switch this flag on and off in a control panel.
Don’t use GDI for time critical stuff in a 3D window, because switching between 3D HW rendering (OpenGL or Direct3D doesn’t matter) and GDI can have a performance impact.
Hi there!
Sorry for posting in the advanced section as a newbie, but I just found this 2d openGL thread. 
As I am currently looking for a hardware accelerated way of displaying 2d maps (evtl. overlayed by vectors) to build up a speedy monitor-interface for the GRASS GIS environment…
Would you recon to look for another library than GLUT / openGL ???
I heard that the enlightenment guy is about to implement a hardware acceleration into the WM to speed it up. that shouldn’t be to different from my idea. Is it possible to do something similar for arrays (in my case GIS pixel data)?
Thanks for any advice and hint, guys…
cheers,
christian
Originally posted by chr_werner@gmx.de:
Would you recon to look for another library than GLUT / openGL ???
I’ve done lots of 2D graphics in OpenGL. You
just use glOrtho and start drawing those
polygons. It certainly fast enough for
everything I’ve needed.
But I don’t know of a good library for doing this. I’d love to find one. I’ve looked at the Enlightenment/EWAS code and its very tied to X Windows, which I don’t use.
Wouldn’t it be -great- if we could
somehow organize ourselves as a community
to create a library for supporting 2D graphics in pure OpenGL.
A decent 2D polygon routine and a nice set of line styles would be a great start. Of
course, then there’s fonts and clipping and hardware speedups and … oh dear :-).
Cheers
Jon.
People often forget that there are 2D functions in OpenGL, glReadPixels, glWritePixels, glPixelZoom etc. In theory you could do blazing fast sprite rendering with hardware flipping and scaling in OpenGL. There are some (serious) problems though. As far as I know there is no equivalent to texture objects for pixel data. This mean all pixels travel over the bus (on PC-like computers, i.e. no unified memory) which will be very slow. Also since most OpenGL drivers are 3d-oriented they tend not to accelerate these functions which of course make them even slower. I know they’re supposed to be fast on the GeForce but I haven’t tested it. In conclusion the fastest alternative (provided the data doesn’t change every frame) is to use textured screen aligned triangles.
I might be writing a GUI library not too long from now that uses OpenGL for all the GUI controls… We’ll see. But if you want 2D elements such as menus or what have you overlayed on a perspective projected scene, what then? Just hack it out (billboards etc. with depth test disabled) or is there some trick you’d use by somehow switching to an ortho projection in mid-stream? As for pixel blitting to textures, it wouldn’t be so bad if you were doing something like an overhead map for an RTS game or somethine like that because you’d probably only be blitting a handful of pixels each frame if that. But full-blown windows and menus and stuff would certainly be a problem.