Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » GUI design question: screen or local coordinates in event handlers?

This thread is locked; no one can reply to it. rss feed Print
GUI design question: screen or local coordinates in event handlers?
axilmar
Member #1,204
April 2001

Hi all.

I need your opinion regarding coordinates passed to widgets during event handling.

Allegro does not support coordinate offsets in drawing, so any drawing within a widget has to be done using global coordinates.

My question is this: what is better, in your opinion?

a) passing screen coordinates (i.e. coordinates relative to screen's top-left corner) in event handlers?
b) passing widget coordinates (i.e. coordinates relative to widget's top-left corner) in event handlers?

My opinion is that a) is better, because since drawing happens using global coordinates, it's better to be consistent in all event handlers. A translateCoords() function can be used to map screen coordinates to widget coordinates, if needed.

What is your opinion?

Oscar Giner
Member #2,207
April 2002
avatar

axilmar said:

Allegro does not support coordinate offsets in drawing, so any drawing within a widget has to be done using global coordinates.

Don't know if you're targeting Allegro 4 or 5. But Allegro 4 has sub-bitmaps, which can be used for this. I guess Allegro 5 has them too, if not then you can use the transform system?

My opinion is also that widgets shouldn't have access to the screen (or backbuffer) directly. They either get a sub-bitmap where they can draw, or a buffer of their size.

Ideally, widgets shouldn't even call drawing functions directly, but instead you'd have some kind of Painter and Style objects they use to draw. No single line of Allegro code in the widgets.

So clearly option b). That's how all GUI's I know work.

axilmar
Member #1,204
April 2001

Don't know if you're targeting Allegro 4 or 5

I am targeting Allegro 5.

Quote:

No single line of Allegro code in the widgets.

It's quite a lot of work to create a painting system, and the GUI will be strictly Allegro. Does it make sense to create Painter and Style classes?

Matthew Leverton
Supreme Loser
January 1999
avatar

I use relative coordinates for everything, including drawing and events. If a widget wants absolute coordinates, then it can call algui_get_absolute(self,&x,&y) and add them together.

axilmar
Member #1,204
April 2001

I use relative coordinates for everything, including drawing and events.

Did you implement a painting system that has offsets, or do you call the function algui_get_absolute() on each paint event?

Matthew Leverton
Supreme Loser
January 1999
avatar

My painting is a bit messy since I retrofitted unbuffered widgets into it, but the idea is that the widget always is drawing to its own canvas in relative terms.

The widget doesn't necessarily need to know if it's buffered or not (although it can check). When the draw function is called, it just starts drawing from (0,0)-(w,h). If it's buffered, it will be drawing to its own bitmap. If it's unbuffered it will be drawing to a sub bitmap or a clipped, transformed rectangle.

There is one exception: I have a hack that allows you to paint (e.g.) shadows outside the widget's canvas area. But the widget isn't responsible for that... the controlling "window manager" does that.

Thomas Fjellstrom
Member #476
June 2000
avatar

My Canva5 library uses transforms to do the positioning and whatnot. Everything is currently drawing direct to the "Drawable" attached to the "View". To speed things Up, I had to cache the transforms though. Right now most of the overhead on my laptop is in the gfx driver, which sucks. There's no way to solve that short of caching the objects themselves, so they don't have to redraw themselves every frame.

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

axilmar
Member #1,204
April 2001

If it's buffered, it will be drawing to its own bitmap. If it's unbuffered it will be drawing to a sub bitmap or a clipped, transformed rectangle.

Interesting. So are you actually using sub-bitmaps on the back buffer or on a memory bitmap?

Matthew Leverton
Supreme Loser
January 1999
avatar

I never use memory bitmaps. Right now everything is either a video bitmap or a sub bitmap of its parent. If the root element is not buffered, then there would be sub bitmaps created on the back buffer.

axilmar
Member #1,204
April 2001

How do you handle exhaustion of vram?

How do you handle widget dimensions that textures cannot have?

How do you make sure your gui does not take vram from the game?

Arthur Kalliokoski
Second in Command
February 2005
avatar

axilmar said:

How do you handle exhaustion of vram?

I've never managed that myself. I used to have a computer with 128Mb of system ram and a non-3d video chip that failed to render some textures when playing the Max Payne I demo, AFAIK that's the only time I've ran out of video ram ever. Although one time Bob was telling me that display lists would outperform ROAM no matter what, and those huge blocks of instructions started swapping to disk, resulting in one frame every 9 seconds vs. 80 fps.

They all watch too much MSNBC... they get ideas.

axilmar
Member #1,204
April 2001

No, I meant in your gui, how do you handle the case of vram exhaustion.

Oscar Giner
Member #2,207
April 2002
avatar

To be honest I wouldn't care much about that. If the user's GPU runs out of vram, then it just doesn't meet the minimum requirements for your software. You can just fall back to memory bitmaps if creating a video bitmap fails, at least it'll work albeit slower.

Go to: