gamedevlists-general — List for discussing general game development issues

[GD-General] Off the shelf scripting languages

[Marc F. <ma...@ma...>]

Hi,

I'm currently having a look at a scripting language to integrate in my game
engine. Building a complete home-made solution is not very realistic due to
the time I can spend on this point, so I'm looking for an existing and well
established one. It seems that Python, Lua and Ruby are popular choices in
that topic.

Does anybody have some pointers that could help me in comparing them and
choosing one, knowing that the criterions are :
- Easiness in binding with C++ classes/integration in the current engine
- Simplicity of its syntax (to have quick up-and-running users/coders)
- Lightweight
- Portable (for console games mainly)
- Extra tools available (debugger, editors, win32 syntax highlighting
controls ...)

thanks.

-Marc Fascia

PS: please excuse me if this message was sent multiple times. I had
apparently some troubles in getting subscribed !

[GD-General] stl on consoles

[Raymond L. M. <ra...@wa...>]

    Hello!  I seriously do not want this to turn into some sort of =
programming war but I just want to hear the experiences and knowledge of =
fellow game developers on this subject.  Here we go.  I've used STL =
before in my PC products and I happen to like it.  I like that the =
algorithms are solid and very complete, and some of the containers such =
as the std::map are invaluable to me.  The biggest gripe I've had with =
it was debugging.  If you have an iterator than getting to the actual =
data in the debugger is horrible (unless there is some other way to =
access it I don't know).  The other problem was with the memory =
allocations and that unless you specify an allocator it allocates as it =
sees fit.  Now on the PC I wasn't too worried about the allocation bit =
and I figured the operating system would take care of the memory =
management and everything would be fine (which it was). Now today I'm =
developing a console game (PS2/XBox) where memory is a precious resource =
not to be spent carelessly.  I know that Pete Isensee has written an =
article on overriding the memory allocator in Game Gems 3 that should =
take care of the allocation problem.  I still get the feeling that STL =
is not very common in console programming and would like to know why.  =
I've written my own templated container types, except for std::map, =
which seem nice and light and much easier to debug but I'm not sure if I =
should use them if STL provides them and there are no penalties for =
using them(memory problems, code bloat, unsuitable routines for the =
cpu).  If you could please tell me if you are working on a console title =
using STL or not and why you do or do not use them.  I appreciate =
everybody's time and thank you.

    Raymond L. Maple
    WayForward Technologies

P.S. I posted this on gda...@li... but was =
told it was an inappropriate subject for that list so I'm posting it =
here also.

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

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

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

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

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

[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

[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

[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

[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: RE: [GD-General] Vector GUIs

[Julien K. <ma...@ju...>]

But with your simple Approach you are loosing the possibility of anchoring
the element to both sides at the same time, which is a natural way to
express rescaling-Behavior in your GUI.

Greets

Julien Koenen


----- Original Message -----
From: <ge...@ub...>
To: <gam...@li...>
Sent: Tuesday, April 08, 2003 12:12 AM
Subject: Re: RE: [GD-General] Vector GUIs


> this is pretty simple to do.
>
> in RF, we have x & y values for our HUD elements.  if they are positive
values, means that it's from the left or bottom, if they're negative values,
means that they are from the right and top.
>
> cheers
>
> mike w
> www.uber-geek.ca
>
>
> >>(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
> >
> >
> >
> >
> >-------------------------------------------------------
> >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_idU7
> >
> >
>
>
> -------------------------------------------------------
> 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: RE: [GD-General] Vector GUIs

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

this is pretty simple to do.

in RF, we have x & y values for our HUD elements.  if they are positive values, means that it's from the left or bottom, if they're negative values, means that they are from the right and top.

cheers

mike w
www.uber-geek.ca 


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

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

[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

[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

[Thatcher U. <tu...@tu...>]

On Apr 04, 2003 at 05:08 -0800, Brian Hook wrote:
> >As an aside:  I'm not sure if it was here or on the algorithms list,
> >but I think I recall someone mentioning something about a SWF
> >renderer.
> 
> I remember seeing references to this as well, I'd swear it was
> something Thatcher was associated with, then again it seems like
> Thatcher is associated with almost everything cool these days ;)

Yes, guilty: http://tulrich.com/geekstuff/gameswf.html

I've gotten a lot of help lately from Ignacio Castanyo which I think
raises the coolness factor 2x.

The current status is slightly more advanced than the web page
suggests, although render improvements are still in progress.  The
antialiased text rendering works pretty well, you can do shapes and
animations and gradients etc pretty well, etc.  We've more or less
given up on antialiasing non-text shapes, since it seems to be pretty
difficult to do efficiently.  That's probably the biggest downside, if
you're looking for a really killer solution to resolution
independence.

I haven't tried it in a game yet, so there are probably a few little
necessary things missing, and also some bugs I'm sure.  But I would
say it's not too far from being usable in a game.

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] Vector GUIs

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

We use flash for our HUD's and menus. IIRC The Star Wars Starfighter guys
did as well. I think you can get a flash renderer as middleware now, but we
rolled our own from the specs (which are publicly available somewhere).

Cheers,
Phil



                                                                           
             "Greg Seegert"                                                
             <greg@stainlessst                                             
             eelstudios.com>                                            To 
             Sent by:                  <gam...@li...urcef 
             gamedevlists-gene         orge.net>                           
             ral-admin@lists.s                                          cc 
             ourceforge.net                                                
                                                                   Subject 
                                       RE: [GD-General] Vector GUIs        
             04/04/2003 04:56                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             gamedevlists-gene                                             
             ra...@li...urcef                                             
                 orge.net                                                  
                                                                           
                                                                           





Performance wise, I think you hit the nail on the head with the problems
you
described.  You could forbid the use of alpha or varying levels of opacity
on your UI elements, which could obviously help fill rate if you z-test.
I'd design the UI for one resolution - say, 1024x768 - and if you're
rendering a background, split the texture up into 12 256x256 textures.
Then
let the gfx hardware handle the scaling for different resolutions.  Results
are pretty good.  And this may not be too practical, but the more ui
elements that shared the same texture the better.  You could batch em all
up
and avoid doing much texture swapping on the hardware.  That method would
obviously work better for ui elements which have a small piece of a texture
tiled over them rather than a full background for example, but it looks way
better than an untextured quad =)

As an aside:  I'm not sure if it was here or on the algorithms list, but I
think I recall someone mentioning something about a SWF renderer.  SWF is
the flash file format, which basically means you'll have a layout tool
pretty much written for you already.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Friday, April 04, 2003 7:26 PM
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_idU7



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

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

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

Tom Hubina mentioned to me that a compromise would be to=
 rasterize 
the vector elements into a 2D mesh and then use texture mapping=
 to 
fill the interiors with some kind of repeating texture.

This works fine if you can use a textured background and you're=
 happy 
with it either A.) repeating differently at different=
 resolutions, or 
B.) having it bilerp up.  The advantage is that drawing the GUI 
requires almost no texture consumption because you don't have 
predefined GUI elements sitting in texture memory, just=
 decorative 
textures (fills, strokes, etc.)  You could also leverage the use=
 of 
vertices by relying on vertex color for added effects, e.g. doing=
 
bevels or gradients.

There are worst case situations where the number of vertices can=
 
skyrocket, e.g. making a round radar image that has to be=
 perfectly 
smooth at 400x300 screen size on a 1600x1200 display (well, the=
 worst 
case would be a full screen circular HUD element at 1600x1200). =
 
Obviously you don't have to hit 1-pixel accuracy, and I'm not=
 even 
sure if vertex counts are really a concern compared to the=
 texture 
savings.

I do think there's a lot to be said for pixel perfect interface 
elements, it adds a level of polish that makes a big difference=
 in 
perceived refinement.  I know every time I play a game that has=
 base 
640x480 interface bitmaps scaled up to the desired resolution=
 that it 
just looks really unpolished to me, but maybe that's my own bias=
 
showing through.

In fact, I've seen this when dealing with 2D games that have nice=
 
looking sprite artwork, then I see a similar game using 3D=
 graphics 
and textures, and the latter looks much worse because of bilerp=
 and 
mip artifacts.

Brian

RE: [GD-General] Vector GUIs

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

>As an aside:  I'm not sure if it was here or on the algorithms=
 list,
>but I think I recall someone mentioning something about a SWF
>renderer.  

I remember seeing references to this as well, I'd swear it was 
something Thatcher was associated with, then again it seems like=
 
Thatcher is associated with almost everything cool these days ;)

>SWF is the flash file format, which basically means
>you'll have a layout tool pretty much written for you already.

There are also SVG tools out there.

Brian

RE: [GD-General] Vector GUIs

[Greg S. <gr...@st...>]

Performance wise, I think you hit the nail on the head with the problems you
described.  You could forbid the use of alpha or varying levels of opacity
on your UI elements, which could obviously help fill rate if you z-test.
I'd design the UI for one resolution - say, 1024x768 - and if you're
rendering a background, split the texture up into 12 256x256 textures.  Then
let the gfx hardware handle the scaling for different resolutions.  Results
are pretty good.  And this may not be too practical, but the more ui
elements that shared the same texture the better.  You could batch em all up
and avoid doing much texture swapping on the hardware.  That method would
obviously work better for ui elements which have a small piece of a texture
tiled over them rather than a full background for example, but it looks way
better than an untextured quad =)

As an aside:  I'm not sure if it was here or on the algorithms list, but I
think I recall someone mentioning something about a SWF renderer.  SWF is
the flash file format, which basically means you'll have a layout tool
pretty much written for you already.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Friday, April 04, 2003 7:26 PM
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_idU7

[GD-General] Vector GUIs

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

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

[GD-General] Looking for audio of a classic Will Wright speech...

[Geoffrey H. <ho...@ca...>]

    Well, it's only two years old, but if it can be preserved, it'll surely
be a classic!
    Will Wright gave the game design keynote at GDC 2001; it was entitled
"Design Plunder." If you were there, you probably remember the talk--it was
awesome and awe-inspiring. Anyway, I'm looking for an audio tape of the
talk. Before we go jumping to conclusions:

1) The official GDC audio sellers, www.tsok.net, do not have that talk. It
apparently was never recorded.
2) Gamasutra never posted a video of the talk, even though I think they did
Marvin Minsky's talk and Seamus Blackley's talk from that year.
3) Mr. Wright himself doesn't know why an audio tape isn't out there, since
he did not tell anyone not to sell or record it. He said he would be
interested if I ever found a tape.
4) I already have the slides from the talk (check
http://thesims.ea.com/us/will/gdc.html).

    Can anyone help me? Any lead, any scrap of audio, any detailed
transcript, any reply would be most appreciated. Thanks for your time,

Geoffrey Hom

---
4th-year biochemistry grad student, Mayo Lab (Caltech/HHMI)
ho...@ca... or geo...@ca...
http://www.geocities.com/geoffhom/
"Attitude, to me, is more important than facts.... I am convinced that life
is 10% what happens to me and 90% how I react to it." --Charles Swindoll

[GD-General] Wow, sorry for that.

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

I tried to copy that email for others at work to see, and hit reply instead
of forward. Sorry.

_______________________
Regards, Gareth Lewin
Programmer, Climax Solent.