I can't understand what you're asking here. Rephrase it as to what you're trying to do please.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

To help clarify (I am also working on this project), we need to know where a given bitmap is in video memory, since everything in OpenGL, to my knowledge, is treated like it is a large virtual screen.

Nope. Textures are separate from the screen. You can draw/use the same texture in many different places so there is no one location you can ask for. You have to keep track of the location of your object in order to know where it is the thing you're looking for.

Is render to texture what you are looking for? There are a lot of tutorials online for that if it's what you want to do. I'm not sure how Allegro handles it internally, there may be a better way.

<offtopic>Wooo! Rarity!</offtopic>

______________________________________As long as it remains classified how long it took me to make I'll be deemed a computer game genius. - William LabbettTheory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why. -UnknownI have recklessly set in motion a chain of events with the potential to so-drastically change the path of my life that I can only find it to be beautifully frightening.

al_set_target_bitmap doesn't always set the target to the backbuffer. The only reason that might happen is if you have an ancient gpu with no fbo support. Why don't you tell us what you're trying to do...

To clarify: Any attempt to use al_set_target_bitmap() followed by al_draw_bitmap() or a similar function will fail, unless the desired target was the screen already.

There are exceptions. If the target was a software bitmap, or a bitmap that has been locked and therefore is a software bitmap, the call will succeed. Any time the program targets a video bitmap, the call of al_draw_bitmap() will end up with the image on the screen.

Attached is an image which helps to display the problem. On the left is the program in OpenGL mode, on the right is the program in DirectDraw mode. The background image is done with putpixel using a chunking algorithm, so it's technically done in software and then drawn to the screen.

The player is somewhat similar, using a paletting technique that is software.The borders of the windows use this as well.

The interiors of the windows are not being cleared by al_clear_to_color() because calling that routine always clears the screen instead. I came up with a workaround that uses FBO's and glDrawPixels which I will post if anyone is curious.

The window in the top right isn't having buttons drawn to it in OGL mode, once again, because those al_draw_bitmap() calls end up on the screen, which then gets cleared by al_clear_to_color().

You seem to be using Aero in either Windows Vista or 7 which leads me to believe that your gpu is reasonably modern, but just in case, what exactly is it? In order to give us some more information, would you be able to compile your game with debug mode Allegro libraries and then attach the generated (once you run your game) allegro.log file to a post on these forums? Barring that there isn't much we can do but guess. Hopefully the log reveals something. It would be even better if you could attach one for OpenGL and one for Direct3D.

I have attached a log generated with the static debug build. Hope it's not too much to sift through. If it is, I can create a different program that minimizes the amount of drawing that needs to be done (I can confirm that all OpenGL programs I've written have the same problem, on multiple systems).

Looking at that log, I'd say try limiting the amount of FBOs to <100 as a test. I had an nvidia card once which would start having errors at around 30 FBOs already. Your log looks like you have 1000ds of FBOs. Since you can only draw to a single one in theory you never need more than one.

So, basically, if you use al_get_opengl_fbo you would call al_remove_opengl_fbo when you're done using the FBO returned by it to free it again. The documentation needs to be more clear on that - calling al_get_opengl_fbo actually allocates an FBO for you, it doesn't simply "get" an already existing one.

Not really sure this is the problem, in theory OpenGL drivers have no limit on the number of FBOs... but worth a try.

Oh man! That did something alright! Stuff is actually displaying now, except that everything is now on the bottom half of the screen. I don't know how much I can share, so here is a makeshift "clear to transparent" function in OpenGL that basically implements: al_clear_to_color(al_map_rgba(0,0,0,0));