RE: [GD-General] Vector GUIs

[Gareth L. <GL...@cl...>]

One trick we use is to build your GUI quads from 16 vertices instaid of 4.
This allows you to keep the corners of the quad from stretching.

In Sudeki we use that for all our dialogs, and the actual texture used by
the GUI quads is just an Oval.

ASCII ART.

0   0.5                       0.5  1.0
+---+--------------------------+---+ 0.0
|   |                          |   |
+---+--------------------------+---+ 0.5
|   |                          |   |
|   |                          |   |
|   |                          |   |
|   |                          |   |
+---+--------------------------+---+ 0.5
|   |                          |   | 
+---+--------------------------+---+ 1.0

The numbers are the UV coords of the texture.

Hope that makes sense.


_______________________
Regards, Gareth Lewin
Programmer, Climax Solent.


> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: 07 April 2003 15:40
> To: gam...@li...
> Subject: RE: [GD-General] Vector GUIs
> 
> 
> I still think the real solution is twofold:
> 
> (1) Have different panels bind to a corner, a middle edge or 
> the centre of
> the screen. This means that as the screen gets bigger, the 
> panels simply
> move apart. Obviously if the thing is a window already, let 
> it live anywhere
> the user puts it.
> 
> (2) Allow people to scale everything up by integers - 2x, 3x, 
> 4x. Change
> your font when you do this (i.e. change the font texture), 
> but otherwise
> just use bilinear/nearest filtering for the rest of the GUI. 
> This keeps the
> text readable on huge monitors.
> 
> 
> Both these are easy to do and easy to author for, and solve 99% of the
> problems.
> 
> 
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> 
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
> 
> > -----Original Message-----
> > From: Brian Hook [mailto:ho...@py...]
> > Sent: 05 April 2003 01:26
> > To: gam...@li...
> > Subject: [GD-General] Vector GUIs
> > 
> > 
> > So I've been thinking about this whole scalable GUI thing 
> some more, 
> > and the "obvious" solution is to do something like make the GUI in 
> > some kind of vector language so that it can scale.
> > 
> > This has a large number of advantages, and the biggest disadvantage 
> > is that you can't do real nice pixel/raster effects such as the 
> > various filters available for Photoshop.  Instead they'd have to be 
> > described procedurally, which might be considered fairly 
> limiting.  A 
> > combination of FreeType fonts coupled with vector GUI descriptions 
> > would seem to allow a great degree of scalability while keeping 
> > things relatively sane for the artist.
> > 
> > To develop the GUI you could use a standard vector drawing package 
> > that exports to a parseable file format such as AI, EPS or 
> SVG.  Then 
> > you either load the file directly or run it through a 
> filter to some 
> > local file format such as a Lua script.  Since SVG is 
> XML-based, you 
> > can easily allow the artist to tag functions for the GUI components 
> > by embedding a key, or you could simply cheese out and tag 
> it as part 
> > of the object ID.
> > 
> > The most difficult part of the process that I can think of is 
> > actually rendering the GUI on modern hardware.  Obviously pixel 
> > plotting is straight out, so you'd probably construct the GUI 
> > elements into textures and use those.  My biggest concern is that 
> > this can eat up a ton of texture space, especially if you 
> have alpha 
> > (precluding the use of 16-bit texture information).
> > 
> > Take a situation where you have a 1280x1024 fullscreen application, 
> > and your total GUI elements come up to an overdraw of 4x (a lot of 
> > the GUI elemenst would presumably be in the form of dialog boxes, 
> > etc. that are temporal).  Assuming you wanted the entire 
> GUI cached, 
> > this could easily add up to a lot of texture memory consumed for a 
> > high-res display.  Obviously you could rasterize into temporary 
> > bitmaps and use liberal amounts of texture destruction, but that 
> > still seems like a lot of overhead just for a GUI.  The problem, of 
> > course, being that since this is scalable, the higher your screen 
> > resolution the more texture memory is consumed by your GUI elements.
> > 
> > Thoughts, comments and "you're smoking crack" comments appreciated.
> > 
> > Brian
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: 
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>