gamedevlists-general

Re: [GD-General] Vector GUIs

[<ge...@ub...>]

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

this reminded me...what about things like the 'blending options' that you can apply to layers in photoshop.  these are all applied in 'real-time' and can be setup for fonts that haven't been rasterized, etc...

wouldn't something similar be possible if you used a freetype library, in-game?

just throwin that out ;}

cheers

mike w
www.uber-geek.ca

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

RE: [GD-General] Vector GUIs

[Brian H. <ho...@py...>]

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

In NextStep/InterfaceBuilder terminology, they calls this=
 "springs 
and bars".  Each edge can be bound to a side of the screen with a=
 
stiff bar or a dynamic spring, and this allows you to choose=
 whether 
something should remain centered, flush left, etc. and whether it=
 
should rescale or stay a fixed size.

Brian

Re: [GD-General] Vector GUIs

[Neil S. <ne...@r0...>]

> In NextStep/InterfaceBuilder terminology, they calls this "springs
> and bars".  Each edge can be bound to a side of the screen with a
> stiff bar or a dynamic spring, and this allows you to choose whether
> something should remain centered, flush left, etc. and whether it
> should rescale or stay a fixed size.

This kind of approach really become useful when you allow layout rules such
as this to be expressed hierarchically.

For example, at the top level of your interface, you might have a basic
"grid" layout, where you specify how many rows and columns you want, and how
big a percentage of the screen width/height each one uses, possibly with
additional constraints to deal with abnormally small (or large) areas.

Then, within each of these grid elements, you could specify another layout
scheme, such as the "springs and bars" method already suggested. Of course,
not all elements of a grid need to have the same sub-layout, and there are
lots of layout schemes you can use (Java has something like this, I think).

By combining these schemes in creative ways, it is quite easy to build
fairly flexible layouts which will deal with a wide range of screen/content
sizes. You will probably still want to perform a certain amount of scaling
of  less-vector-oriented components (such as bitmap tiles) to make
everything fit elegantly, but you can restrict this scaling to 'nice' scale
factors like 2X, 3X, etc.

You will probably still need to use a more arbitrary scale for things like
background images or videos, but it's not too bad if they're all you need to
worry about.

- Neil.

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
> 

Re: [GD-General] Vector GUIs

[Javier A. <ja...@py...>]

In Praetorians we sort of did that but with more configurability. We would
have "panel" textures that have these same 9 sections, but each section can
have a texture. The way you describe it there, only the corners have actual
textures, the rest simply has a stretched pixel texture. In our case, your
0.5's would be 0.3 to 0.7 or so, actually expressed in pixels inside the GUI
text resource description.

About layout, we had the layout coordinates expressed in several coordinate
systems. I'll describe using examples rather than a detailed run-through:

"10 10 100 100" - your typical 90-pixel square with 10-pixel margins above
and to the left.

"^0 ^0 %50 %50" - A centered rect half the size of the screen

">20 ^-10 400 %75" - A rect that is 75% the height of the screen, 400 pixels
wide, 10 pixels above the vertically centered position, and leaving 20
pixels between its right edge and the rightmost edge of the screen.

The actual code for handling this is very simple, it takes a "parent"
control inside which the current control is being created, the coordinate
styles (pixels, percents, right-align or centered) and coordinate values for
the control, and outputs a rectangle (in pixels) relative to the parent's
x,y:

void AdjustStyleRect(TRect *pDest, const TRect &src, const TRect &style,
const TRect &parent)
{
  if (style.w == RS_PERCENT)
    pDest->w = parent.w * src.w / 100;
  else
    pDest->w = src.w;

  if (style.x == RS_RIGHTALIGN)
    pDest->x = parent.w - pDest->w - src.x;
  else if (style.x == RS_CENTER)
    pDest->x = (parent.w - pDest->w)/2 + src.x;
  else if (style.x == RS_PERCENT)
    pDest->x = parent.w * src.x / 100;
  else
    pDest->x = src.x;

  if (style.w == RS_RIGHTALIGN)
    pDest->w = parent.w - pDest->x - src.w;
  else if (style.w == RS_CENTER)
    pDest->w = parent.w - pDest->x*2 - src.w;

  // ... do the same for te Y axis
}

The code for reading the coordinates is left as an exercise for the reader.
This means, in approx 100 lines you have a recursive, fully anchorable GUI
layout handler with relative or absolute coordinates and a couple of extra
bits for flexibility.

Our "control style" descriptions contain not just textures, images, fonts
and colors, but also flags to control stetching or tiling of the textures,
text scaling and formatting, and stuff like that.

  Javier Arevalo
  Pyro Studios

Gareth Lewin wrote:
> 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.

RE: [GD-General] Vector GUIs

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

> From: Javier Arevalo [mailto:ja...@py...]
> In Praetorians we sort of did that but with more 
> configurability. We would
> have "panel" textures that have these same 9 sections, but 
> each section can
> have a texture. The way you describe it there, only the 
> corners have actual
> textures, the rest simply has a stretched pixel texture. In 
> our case, your
> 0.5's would be 0.3 to 0.7 or so, actually expressed in pixels 
> inside the GUI
> text resource description.

Yes, your system takes the same idea one step forward, but ours is actually
done by the UI designer himself, he has all the flexibility. Just just
models a scene in Maya. He did it as a texture saving technique as apposed
to a resolution independant one, since our title is xbox only.

Also, it suits our style. Our dialog oxes are very simple clean squares with
rounded corners.

But I will keep what you said in mind for the future ;)

_______________________
Regards, Gareth Lewin
Programmer, Climax Solent.

(To anyone outside Climax, sorry for the disclaimer below)



DISCLAIMER: Unless otherwise expressly stated, this message does not create
or vary any contractual relationship between you and Climax Development Ltd.
The contents of this e-mail may be confidential and if you have received it
in error, please delete it from your system, destroy any hard copies and
contact the originator of the email. In accordance with the
Telecommunications (Lawful Business Regulations) (Interception of
Communications) Regulations 2000 the Company reserves the right and, may at
any time, monitor and intercept (but not record) e-mails to establish if
they are relevant to its business.

Re: [GD-General] Vector GUIs

[Noel L. <ll...@co...>]

On Wed, 09 Apr 2003 12:16:04 +0100
Gareth Lewin <GL...@cl...> wrote:

> He did it as a texture saving technique as apposed
> to a resolution independant one, since our title is xbox only.

Even on an Xbox-only title it's worth having resolution-independent GUI
components so you can deal better with HDTV modes.

Having said that, we also take it into account and ended up not
supporting HDTV in MechAssault. 


--Noel
ll...@co...

Re: [GD-General] Vector GUIs

[<phi...@pl...>]

Noel:
> Having said that, we also take it into account and ended up not
supporting HDTV in MechAssault.

I wonder what proportion of console titles actually support HDTV, beyond
480p. All those extra pixels have to come from somewhere. 480p at 60fps, or
1080i at 15fps. 1080i at 60fps, with your 480p/i mode drawing 25% of
potential. Supporting HDTV properly, sort of implies short-changing people
without it, which is 99% of your market (self included).

Cheers,
Phil

Re: [GD-General] Vector GUIs

[Noel L. <ll...@co...>]

phi...@pl... wrote:

> > Having said that, we also take it into account and ended up not
> supporting HDTV in MechAssault.
> 
> I wonder what proportion of console titles actually support HDTV, beyond
> 480p. All those extra pixels have to come from somewhere. 480p at 60fps, or
> 1080i at 15fps. 1080i at 60fps, with your 480p/i mode drawing 25% of
> potential. Supporting HDTV properly, sort of implies short-changing people
> without it, which is 99% of your market (self included).

By the way, my original comment was supposed to be "we also DID NOT
take it into account..." otherwise it makes no sense :-)

When I think of HDTV in consoles I'm mostly thinking of 480p, which is
not that huge a step up performance-wise but looks great on all
widescreen TVs.  Maybe 720 would be doable, but I agree that 1080i is
just a killer.  Both the fill rate and the sheer amount of memory
required is huge. 


--Noel

RE: [GD-General] Vector GUIs

[Mick W. <mi...@ne...>]

We did 720p for Tony Hawk 4 on XBox, still maintained mostly 60fps.
1080i was also reasonably, but I think we ran out of memory.  It looked
pretty cool though.

I've always found that you can scale HUD bitmaps with impunity,
especially if they are destined for display on a TV.   Even on HDTV, the
typical console user is sitting much further away from the TV than a
typical PC user is from their monitor, so they don't notice a few
stretched or missing pixels.

When changing from 4:3 to 16:9, we actually just correct the 3D
elements.  2D stuff we just leave it as is.  Nobody notices.

I know one person who watches regular 4:3 TV stretched out to 16:9,
because he feels it looks better.  The brain can compensate for a lot,
and the average user does not mull on these things. 

Mick

> -----Original Message-----
> From: phi...@pl...
> Sent: Wednesday, April 09, 2003 9:16 AM
> Noel:
> > Having said that, we also take it into account and ended up not
> supporting HDTV in MechAssault.
> 
> I wonder what proportion of console titles actually support 
> HDTV, beyond 480p. All those extra pixels have to come from 
> somewhere. 480p at 60fps, or 1080i at 15fps. 1080i at 60fps, 
> with your 480p/i mode drawing 25% of potential. Supporting 
> HDTV properly, sort of implies short-changing people without 
> it, which is 99% of your market (self included).
> 
> Cheers,
> Phil

RE: [GD-General] Vector GUIs

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

> Also, it suits our style. Our dialog oxes are very simple 
> clean squares with
> rounded corners.

Sorry, bad English there, should be dialog oxen, and the breeding techniques
used to get them both clean and with rounded corners is (c) Climax 2003.


DISCLAIMER: Unless otherwise expressly stated, this message does not create
or vary any contractual relationship between you and Climax Development Ltd.
The contents of this e-mail may be confidential and if you have received it
in error, please delete it from your system, destroy any hard copies and
contact the originator of the email. In accordance with the
Telecommunications (Lawful Business Regulations) (Interception of
Communications) Regulations 2000 the Company reserves the right and, may at
any time, monitor and intercept (but not record) e-mails to establish if
they are relevant to its business.

RE: [GD-General] Vector GUIs

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

Supporting widescreen is just a matter of changing aspect ratio. It's still
640x480, but it's 16:9 instead of 4:3. Usually relatively painless to
support.

Higher resolutions - yeah, they're a pain. You either run out of memory or
fillrate or both.


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: phi...@pl...
> [mailto:phi...@pl...]
> Sent: 09 April 2003 17:16
> To: gam...@li...
> Subject: Re: [GD-General] Vector GUIs
> 
> 
> 
> 
> 
> 
> Noel:
> > Having said that, we also take it into account and ended up not
> supporting HDTV in MechAssault.
> 
> I wonder what proportion of console titles actually support 
> HDTV, beyond
> 480p. All those extra pixels have to come from somewhere. 
> 480p at 60fps, or
> 1080i at 15fps. 1080i at 60fps, with your 480p/i mode drawing 25% of
> potential. Supporting HDTV properly, sort of implies 
> short-changing people
> without it, which is 99% of your market (self included).
> 
> Cheers,
> Phil
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of 
> TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you 
> feeling lost and 
> disoriented. TotalView can help you find your way. Available 
> on major UNIX 
> and Linux platforms. Try it free. www.etnus.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
>