|
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? 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
|
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
|
Oscar Giner said: 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
|
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
|
Matthew Leverton said: 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
|
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
|
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. -- |
axilmar
Member #1,204
April 2001
|
Matthew Leverton said: 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
|
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
|
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
|
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. -- |
|