Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Target bitmap x and y screen coordinates?

This thread is locked; no one can reply to it. rss feed Print
Target bitmap x and y screen coordinates?
dancinninja
Member #13,260
August 2011

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
Second in Command
February 2005
avatar

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

― Robert A. Heinlein

SaltyJustice
Member #4,231
January 2004
avatar

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
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

SaltyJustice
Member #4,231
January 2004
avatar

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
Member #7,719
August 2006
avatar

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 Labbett
Theory 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. -Unknown
I 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.

Trent Gamblin
Member #261
April 2000
avatar

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
Member #4,231
January 2004
avatar

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
Member #476
June 2000
avatar

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?

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Trent Gamblin
Member #261
April 2000
avatar

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
Member #4,231
January 2004
avatar

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
Supreme Loser
January 1999
avatar

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

Trent Gamblin
Member #261
April 2000
avatar

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
Member #358
May 2000

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.

--
"Either help out or stop whining" - Evert

dancinninja
Member #13,260
August 2011

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
Member #261
April 2000
avatar

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

Thomas Fjellstrom
Member #476
June 2000
avatar

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.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Matthew Leverton
Supreme Loser
January 1999
avatar

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

Elias
Member #358
May 2000

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

--
"Either help out or stop whining" - Evert

Go to: