Thread: [GD-General] GUI Design
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Chris B. <Chr...@ma...> - 2003-01-23 00:14:30
|
I've been building a GUI for my game but from day 1 have had a design issue I've been ignoring. From the beginning I've coded the coordinate system to OpenGL's bottom left origin. This is a minor pain as I'm the only one who needs to worry about the coordinates in the menu xml files (for now). The problem however is when I resize the screen everything remains squished in the bottom left corner of the screen. The only ay I can think of solving the problem so it looks 'normal' is to provide some kind of virtual scaling system that the menu is designed against that is then translated in to screen coordinates. For example I could use something simple like 100% equalling the width of the screen, so a box might be 20% wide 15% high at position 5%,5%. How have you guys solved this problem? My solution presented seems like it'll add a whole lot more math to the GUI to do all the translations for the virtual screen space. Thoughts? Chris Brodie NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. |
|
From: Jason M. <jma...@li...> - 2003-01-23 00:42:45
|
Yeah I would recommend using values between 0.0 and 1.0 as a percentage of the width or height of the screen like you said, you can convert to actual screen coordinates by just multiplying the the screen width or height then. Another option is to design the GUI layout in a fixed resolution and then to convert them into a different resolution apply a scaling factor. Say you have a point (x,y) in 640x480 layout and your screen is in resolution WxH, then to find the point (x',y') in screen space: x' = x * (W / 640); y' = y * (H / 480); -Jason ----- Original Message ----- From: "Chris Brodie" <Chr...@ma...> To: <gam...@li...> Sent: Wednesday, January 22, 2003 4:14 PM Subject: [GD-General] GUI Design > I've been building a GUI for my game but from day 1 have had a design issue I've been ignoring. From the beginning I've coded the coordinate system to OpenGL's bottom left origin. This is a minor pain as I'm the only one who needs to worry about the coordinates in the menu xml files (for now). > > The problem however is when I resize the screen everything remains squished in the bottom left corner of the screen. The only ay I can think of solving the problem so it looks 'normal' is to provide some kind of virtual scaling system that the menu is designed against that is then translated in to screen coordinates. For example I could use something simple like 100% equalling the width of the screen, so a box might be 20% wide 15% high at position 5%,5%. > > How have you guys solved this problem? My solution presented seems like it'll add a whole lot more math to the GUI to do all the translations for the virtual screen space. > > Thoughts? > > Chris Brodie > > > NOTICE > This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 |
|
From: Ray <ra...@gu...> - 2003-01-23 05:16:28
|
Make sure you take window aspect into account. For example, if you're in parhelia triple-headed mode, your aspect is really wide and you don't want things horribly stretched. - Ray Jason Maynard wrote: > Yeah I would recommend using values between 0.0 and 1.0 as a percentage of > the width or height of the screen like you said, you can convert to actual > screen coordinates by just multiplying the the screen width or height then. > > Another option is to design the GUI layout in a fixed resolution and then to > convert them into a different resolution apply a scaling factor. Say you > have a point (x,y) in 640x480 layout and your screen is in resolution WxH, > then to find the point (x',y') in screen space: > > x' = x * (W / 640); > y' = y * (H / 480); > > -Jason |
|
From: Brian H. <bri...@py...> - 2003-01-23 00:48:07
|
On Thu, 23 Jan 2003 11:14:03 +1100, Chris Brodie wrote: >think of solving the problem so it looks 'normal' is to provide= some >kind of virtual scaling system that the menu is designed= against >that is then translated in to screen coordinates. The NextStep Interface Builder handled this in a fairly elegant manner using "bars and springs". In the GUI designer you could specify a GUI widget as being tied to another either using a bar= or a spring. A bar would always keep that component a fixed distance from an= edge. For example, if you wanted to have a row of buttons aligned on= the right hand side of a resizable window. Springs, as you would guess, stretch to fit. This is how you= would specify, say, a button that is always centered. Each side of a widget could have a bar or a spring, so you could have something= that was always centered horizontally but always a fixed distance from= the top edge of the parent component, etc. >For example I >could use something simple like 100% equalling the width of the >screen, so a box might be 20% wide 15% high at position 5%,5%. That's the typical fashion. The downside is that you give up= precise measurements and it just feels a little "weird" to many people. = And, of course, there's the whole issue of scaling GUI graphics,= period. Another compromise is to work in some idealized screen resolution= that you don't plan on exceeding, like 1600x1200, and then scale= down from there. That way your designers are always working in pixel= units instead of percentages. >How have you guys solved this problem? My solution presented= seems >like it'll add a whole lot more math to the GUI to do all the >translations for the virtual screen space.] That amount of math should be relatively trivial though in the= grand scheme of things. -Hook |
|
From: Jamie F. <ja...@qu...> - 2003-01-23 10:50:54
|
our engine lets the user specify a virtual coordinate system within which they can work, independently of the actual display resolution. works fine :) what you do as regards multiple monitors and positioning / scaling components within that virtual space is up to you :) j -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Chris Brodie Sent: 23 January 2003 00:14 To: 'gam...@li...' Subject: [GD-General] GUI Design I've been building a GUI for my game but from day 1 have had a design issue I've been ignoring. From the beginning I've coded the coordinate system to OpenGL's bottom left origin. This is a minor pain as I'm the only one who needs to worry about the coordinates in the menu xml files (for now). The problem however is when I resize the screen everything remains squished in the bottom left corner of the screen. The only ay I can think of solving the problem so it looks 'normal' is to provide some kind of virtual scaling system that the menu is designed against that is then translated in to screen coordinates. For example I could use something simple like 100% equalling the width of the screen, so a box might be 20% wide 15% high at position 5%,5%. How have you guys solved this problem? My solution presented seems like it'll add a whole lot more math to the GUI to do all the translations for the virtual screen space. Thoughts? Chris Brodie NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557 |
|
From: Noel L. <ll...@co...> - 2003-01-23 11:38:12
|
On Thu, 23 Jan 2003 10:51:36 +0000 Jamie Fowlston <ja...@qu...> wrote: > our engine lets the user specify a virtual coordinate system within which > they can work, independently of the actual display resolution. works fine :) > > what you do as regards multiple monitors and positioning / scaling > components within that virtual space is up to you :) How does that work for varying aspect ratios? If the designer creates a GUI with a certain aspect ratio in mind, and then you switch to HDTV mode, are components rearranged correctly? I'm thinking more along the lines of those Java-style layouts, that way they can put a left box with a bunch of stuff inside, a bottom box, etc. Then changing the screen ratio would make everything work perfectly. --Noel ll...@co... |
|
From: Jamie F. <ja...@qu...> - 2003-01-23 11:56:43
|
it's really up to the user to decide how they want to deal with widescreen (or other aspect ratios). the engine also provides the physical aspect ratio. i found that our gui looked fine in widescreen (even though it was scaled to the wrong aspect ratio), so left it alone. however, i played tricks with the field of view when we move to widescreen (we don't do what most apps do). the bars and springs that brian mentioned seem an excellent way of doing a more general solution, but for most game apps i'm sure a few boxes in the right places would do the job well enough. jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Noel Llopis Sent: 23 January 2003 11:38 To: gam...@li... Subject: Re: [GD-General] GUI Design On Thu, 23 Jan 2003 10:51:36 +0000 Jamie Fowlston <ja...@qu...> wrote: > our engine lets the user specify a virtual coordinate system within which > they can work, independently of the actual display resolution. works fine :) > > what you do as regards multiple monitors and positioning / scaling > components within that virtual space is up to you :) How does that work for varying aspect ratios? If the designer creates a GUI with a certain aspect ratio in mind, and then you switch to HDTV mode, are components rearranged correctly? I'm thinking more along the lines of those Java-style layouts, that way they can put a left box with a bunch of stuff inside, a bottom box, etc. Then changing the screen ratio would make everything work perfectly. --Noel ll...@co... ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557 |
|
From: Nicolas R. <nic...@fr...> - 2003-01-24 13:04:47
|
Helo, Our engine is defining "windows" which look like a mix between MFC CWnd and HWND :) Any time a window is receiving a "size" event (from windows when the window is the top-most backbuffer, or from the engine for child-windows) a "OnSize" method is called. The first thing OnSize does is to call each child's OnParentSize (leaving them a chance to resize themselves), finally the OnSize may "re-position" child windows as wanted. A "glue" mechanism is supported to help in most cases. A "glue" tells that a border should be "glued" to a parent's border with a given amount. For exemple, window A left-border should be glued to parent's right-border - 100 pixels. Pixels can be replaced w/ width relative values. You should keep pixels because of UI designers usually given you nice 49x71 buttons (not speaking about window backgrounds :) ) that usually cannot be resized at all :) Nicolas. -----Original Message----- How have you guys solved this problem? My solution presented seems like it'll add a whole lot more math to the GUI to do all the translations for the virtual screen space. |
|
From: mike w. <mi...@ub...> - 2003-01-24 17:32:38
|
what we do with our engine is read the coordinates differently based on whether they are positive or negative values. so if you have a hud or menu item that has a positive coordinate, then the item is positioned that far from the top or left hand side of the screen. if it is a negative value, then it's from the bottom or right hand side of the screen. so a layout like this gives us something that is 10 pixels from the left hand side of the screen, 35 pixels from the bottom... [health] type = numeric frame = healthindicator.bmp framealpha = a_healthindicator.bmp framex = 10 framey = -35 indicatoroffsetx = 35 indicatoroffsety = -10 font = 14 width = 3 and this entry gives me a hud indicator that is 100 pixels from the right hand side of the screen, and -35 pixels from the bottom. works well, and your hud auto-scales to all resolutions (within reason). [pistol_shell] type = numeric style = magazine frame = bulletindicator.bmp framealpha = a_bulletindicator.bmp framex = -100 framey = -35 indicatoroffsetx = 10 indicatoroffsety = -10 font = 14 width = 3 active = false you can get the source code that details how this is done (as well as the rest of our engine) from our project site at http://rfactory.uber-geek.ca hope this helps cheers mike w www.uber-geek.ca ----- Original Message ----- From: "Chris Brodie" <Chr...@ma...> To: <gam...@li...> Sent: Wednesday, January 22, 2003 4:14 PM Subject: [GD-General] GUI Design > I've been building a GUI for my game but from day 1 have had a design issue I've been ignoring. From the beginning I've coded the coordinate system to OpenGL's bottom left origin. This is a minor pain as I'm the only one who needs to worry about the coordinates in the menu xml files (for now). > > The problem however is when I resize the screen everything remains squished in the bottom left corner of the screen. The only ay I can think of solving the problem so it looks 'normal' is to provide some kind of virtual scaling system that the menu is designed against that is then translated in to screen coordinates. For example I could use something simple like 100% equalling the width of the screen, so a box might be 20% wide 15% high at position 5%,5%. > > How have you guys solved this problem? My solution presented seems like it'll add a whole lot more math to the GUI to do all the translations for the virtual screen space. > > Thoughts? > > Chris Brodie > > > NOTICE > This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X