Target bitmap x and y screen coordinates?
dancinninja

Hi all. I have a problem, and I'm hoping one of you would be so kind as to help me!

I am trying to run some OpenGL with my Allegro, but I got stuck. When I use:

glBindTexture(GL_TEXTURE_2D, al_get_opengl_texture(bitmap));

(where "bitmap" is the ALLEGRO_BITMAP that I want), I realize that I need the x and y position of the "target" bitmap [set with al_set_target_bitmap(parentBitmap)].

Is there any way to find out where on the screen the target bitmap is?

Thank you!

Arthur Kalliokoski

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

SaltyJustice

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.

al_set_target_bitmap() doesn't seem to work, as it always sets the target to the screen (backbuffer). In DirectDraw mode, there is no problem.

Thomas Fjellstrom

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.

SaltyJustice

If that's the case, then we need a way to set the target bitmap in OpenGL mode.
al_set_target_bitmap() doesn't work, it always sets it to the backbuffer, as above. Anyone know how we can do that?

someone972

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>

Trent Gamblin

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...

SaltyJustice

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().

Thomas Fjellstrom

Allegro already uses FBOs, so if you have them, drawing to bitmaps should work. glDrawPixels isn't typically something that's used with FBOs afaik, its for raw texture access.

Have you made sure you have the latest drivers for your card (from the manufacturer, not from Microsoft), and that the card and drivers both support FBOs in OpenGL?

Trent Gamblin

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.

SaltyJustice

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).

Matthew Leverton

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

Trent Gamblin

Yeah, if it's happening on multiple systems then I'm led to believe you're doing something wrong. I would like to see a minimal example as well. Throw in the log for good measure.

Elias

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.

dancinninja

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));

http://www.pastie.org/2387940

mBitmap is the ALLEGRO_BITMAP, mWidth and mHeight are the width and height of the bitmap.

The only change from the "original" code is the last line: al_remove_opengl_fbo(mBitmap);

This, for some reason, makes everything scrunched at the bottom, even stuff we're not using OpenGL for!

Thanks all!

Trent Gamblin

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

Thomas Fjellstrom

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

Might not have made it into the version they are using? I thought it was pretty new. May have made it into the latest stable release, I haven't checked.

Matthew Leverton

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

Elias

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

Yes, Allegro itself will never use more. But each call to al_get_opengl_fbo() will allocate a new one which is only freed with al_remove_opengl_fbo().

Thread #608089. Printed from Allegro.cc