RE: [GD-General] Vector GUIs

[Tom F. <to...@mu...>]

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