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

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>

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.

Can you supply, say, a 15 line program that illustrates the problem?

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.

I thought were were limiting to ~8 fbos in the OpenGL code now?

Is there a reason you are using OpenGL specific calls for things like this? Why not just use native Allegro calls?