gamedevlists-general

RE: [GD-General] Scaling GUI graphics

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

What about using a vector format for the graphics as apposed to a bitmap
format ?

I've never tried this, but WMFs for example are very well documented, and
even Photoshop (if I understand my artists correctly) have moved over to
this. For fonts just use proper ttf.

If you insist on bitmap graphics, fonts are a special case and a simple one
at that. just sample the ttf to a bitmap scaled based on your background.

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]
Sent: 25 June 2002 04:23
To: gam...@li...
Subject: [GD-General] Scaling GUI graphics


Okay, this is a common problem that I'm sure others have dealt with on 
numerous occasions, but I have yet to deal with it so I'm curious what the 
conventional wisdom is.

Basically it's the age old problem of having an interface that looks good 
at all resolutions.  AFAICT, the standards are:

- do low res graphics for everything, then zoom appropriately (leads to 
serious blurring)

- do multiple resolution graphics (lots of content)

- render GUI graphics into textures/images instead of using prefab images 
(i.e. actually write line/circle/filled region software renderers)

- don't scale, just make everything smaller (8x8 font at 1600x1200...ewwww)

Anyone find a solution that doesn't have a glaring flaw, unlike the 
above?  I suppose the closest I can think of is to do everything in high 
resolution, e.g. for a 1600x1200 interface, and then resample down for 
lower resolution displays.

Brian



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.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] Scaling GUI graphics

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

My favourite solution is to scale, but only by powers of two. So you design
GUI graphics for 640x480. For 800x600 and 1024x768, you don't scale, you
just move them further apart (i.e. the bits stick to the cornr, edge or
centre as required). For 1280x1024 and above, you double the size so that at
least stuff is readable.

To do the scale x2 you can either just do the bilinear filter thing (which
doesn't look too bad on power-of-two scales), or just get the artists to do
second versions. Or mix'n'match (e.g. hand-done bigger font, but scaled
backgrounds).

Tom Forsyth - purely hypothetical Muckyfoot bloke.

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:bri...@py...]
> Sent: 25 June 2002 04:23
> To: gam...@li...
> Subject: [GD-General] Scaling GUI graphics
> 
> 
> Okay, this is a common problem that I'm sure others have 
> dealt with on 
> numerous occasions, but I have yet to deal with it so I'm 
> curious what the 
> conventional wisdom is.
> 
> Basically it's the age old problem of having an interface 
> that looks good 
> at all resolutions.  AFAICT, the standards are:
> 
> - do low res graphics for everything, then zoom appropriately 
> (leads to 
> serious blurring)
> 
> - do multiple resolution graphics (lots of content)
> 
> - render GUI graphics into textures/images instead of using 
> prefab images 
> (i.e. actually write line/circle/filled region software renderers)
> 
> - don't scale, just make everything smaller (8x8 font at 
> 1600x1200...ewwww)
> 
> Anyone find a solution that doesn't have a glaring flaw, unlike the 
> above?  I suppose the closest I can think of is to do 
> everything in high 
> resolution, e.g. for a 1600x1200 interface, and then resample 
> down for 
> lower resolution displays.
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.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] Scaling GUI graphics

[Kent Q. <ken...@co...>]

We just built a skinnable GUI for a game we're doing. All the graphics
in the game are built from individual components at load time, with
the layout described in an XML file. We haven't supported any form of
scaling, as it's my experience that scaling always looks like hell.
But we do support tiling, so what we do is build a background texture
that's seamlessly tileable, and lay that down first. Then we place
interface elements on top of that.

It let me use mixed file formats (highly compressed jpgs for the
background, GIFs for basic interface elements, and PNGs where I needed
transparency), and in addition to increased flexibility, we took about
1.5 meg of interface graphics and compressed it to less than 300K.

    Kent


Tuesday, June 25, 2002, 6:19:55 AM, you wrote:

TF> My favourite solution is to scale, but only by powers of two. So you design
TF> GUI graphics for 640x480. For 800x600 and 1024x768, you don't scale, you
TF> just move them further apart (i.e. the bits stick to the cornr, edge or
TF> centre as required). For 1280x1024 and above, you double the size so that at
TF> least stuff is readable.

TF> To do the scale x2 you can either just do the bilinear filter thing (which
TF> doesn't look too bad on power-of-two scales), or just get the artists to do
TF> second versions. Or mix'n'match (e.g. hand-done bigger font, but scaled
TF> backgrounds).

TF> Tom Forsyth - purely hypothetical Muckyfoot bloke.

TF> This email is the product of your deranged imagination,
TF> and does not in any way imply existence of the author.

>> -----Original Message-----
>> From: Brian Hook [mailto:bri...@py...]
>> Sent: 25 June 2002 04:23
>> To: gam...@li...
>> Subject: [GD-General] Scaling GUI graphics
>> 
>> 
>> Okay, this is a common problem that I'm sure others have 
>> dealt with on 
>> numerous occasions, but I have yet to deal with it so I'm 
>> curious what the 
>> conventional wisdom is.
>> 
>> Basically it's the age old problem of having an interface 
>> that looks good 
>> at all resolutions.  AFAICT, the standards are:
>> 
>> - do low res graphics for everything, then zoom appropriately 
>> (leads to 
>> serious blurring)
>> 
>> - do multiple resolution graphics (lots of content)
>> 
>> - render GUI graphics into textures/images instead of using 
>> prefab images 
>> (i.e. actually write line/circle/filled region software renderers)
>> 
>> - don't scale, just make everything smaller (8x8 font at 
>> 1600x1200...ewwww)
>> 
>> Anyone find a solution that doesn't have a glaring flaw, unlike the 
>> above?  I suppose the closest I can think of is to do 
>> everything in high 
>> resolution, e.g. for a 1600x1200 interface, and then resample 
>> down for 
>> lower resolution displays.
>> 
>> Brian
>> 
>> 
>> 
>> -------------------------------------------------------
>> Sponsored by:
>> ThinkGeek at http://www.ThinkGeek.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
>> 


TF> -------------------------------------------------------
TF> Sponsored by:
TF> ThinkGeek at http://www.ThinkGeek.com/
TF> _______________________________________________
TF> Gamedevlists-general mailing list
TF> Gam...@li...
TF> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
TF> Archives:
TF> http://sourceforge.net/mailarchive/forum.php?forum_id=557


-- 
Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com

RE: [GD-General] Scaling GUI graphics

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

The other cute trick I've heard of is to bite the bullet and put Flash in
the game. Then the artists can do front ends and GUIs all they like, and the
graphics coders don't have to be involved at all, so we can get on with the
actual 3D stuff. Which appeals to me, seeing as the last fancy GUI we did
chewed 6 months of a programmer's time. That was bad.

Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Kent Quirk [mailto:ken...@co...]
> Sent: 25 June 2002 14:59
> To: Tom Forsyth
> Cc: Brian Hook; gam...@li...
> Subject: Re: [GD-General] Scaling GUI graphics
> 
> 
> We just built a skinnable GUI for a game we're doing. All the graphics
> in the game are built from individual components at load time, with
> the layout described in an XML file. We haven't supported any form of
> scaling, as it's my experience that scaling always looks like hell.
> But we do support tiling, so what we do is build a background texture
> that's seamlessly tileable, and lay that down first. Then we place
> interface elements on top of that.
> 
> It let me use mixed file formats (highly compressed jpgs for the
> background, GIFs for basic interface elements, and PNGs where I needed
> transparency), and in addition to increased flexibility, we took about
> 1.5 meg of interface graphics and compressed it to less than 300K.
> 
>     Kent
> 
> 
> Tuesday, June 25, 2002, 6:19:55 AM, you wrote:
> 
> TF> My favourite solution is to scale, but only by powers of 
> two. So you design
> TF> GUI graphics for 640x480. For 800x600 and 1024x768, you 
> don't scale, you
> TF> just move them further apart (i.e. the bits stick to the 
> cornr, edge or
> TF> centre as required). For 1280x1024 and above, you double 
> the size so that at
> TF> least stuff is readable.
> 
> TF> To do the scale x2 you can either just do the bilinear 
> filter thing (which
> TF> doesn't look too bad on power-of-two scales), or just get 
> the artists to do
> TF> second versions. Or mix'n'match (e.g. hand-done bigger 
> font, but scaled
> TF> backgrounds).
> 
> TF> Tom Forsyth - purely hypothetical Muckyfoot bloke.
> 
> TF> This email is the product of your deranged imagination,
> TF> and does not in any way imply existence of the author.
> 
> >> -----Original Message-----
> >> From: Brian Hook [mailto:bri...@py...]
> >> Sent: 25 June 2002 04:23
> >> To: gam...@li...
> >> Subject: [GD-General] Scaling GUI graphics
> >> 
> >> 
> >> Okay, this is a common problem that I'm sure others have 
> >> dealt with on 
> >> numerous occasions, but I have yet to deal with it so I'm 
> >> curious what the 
> >> conventional wisdom is.
> >> 
> >> Basically it's the age old problem of having an interface 
> >> that looks good 
> >> at all resolutions.  AFAICT, the standards are:
> >> 
> >> - do low res graphics for everything, then zoom appropriately 
> >> (leads to 
> >> serious blurring)
> >> 
> >> - do multiple resolution graphics (lots of content)
> >> 
> >> - render GUI graphics into textures/images instead of using 
> >> prefab images 
> >> (i.e. actually write line/circle/filled region software renderers)
> >> 
> >> - don't scale, just make everything smaller (8x8 font at 
> >> 1600x1200...ewwww)
> >> 
> >> Anyone find a solution that doesn't have a glaring flaw, 
> unlike the 
> >> above?  I suppose the closest I can think of is to do 
> >> everything in high 
> >> resolution, e.g. for a 1600x1200 interface, and then resample 
> >> down for 
> >> lower resolution displays.
> >> 
> >> Brian
> >> 
> >> 
> >> 
> >> -------------------------------------------------------
> >> Sponsored by:
> >> ThinkGeek at http://www.ThinkGeek.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
> >> 
> 
> 
> TF> -------------------------------------------------------
> TF> Sponsored by:
> TF> ThinkGeek at http://www.ThinkGeek.com/
> TF> _______________________________________________
> TF> Gamedevlists-general mailing list
> TF> Gam...@li...
> TF> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> TF> Archives:
> TF> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> 
> -- 
> Kent Quirk, CTO, CogniToy
> ken...@co...
> http://www.cognitoy.com
> 

Re: [GD-General] Scaling GUI graphics

[Mickael P. <mpo...@ed...>]

> The other cute trick I've heard of is to bite the bullet and put Flash in
> the game. Then the artists can do front ends and GUIs all they like, and
the
> graphics coders don't have to be involved at all, so we can get on with
the
> actual 3D stuff. Which appeals to me, seeing as the last fancy GUI we did
> chewed 6 months of a programmer's time. That was bad.

Actually it's the solution retained for V-Rally 3 on the PlayStation 2.

All the interface has been crafted by artists, and the PlayStation
try to display it in real time :))

It's pretty slow, but well, if it's for settings in a racing game,
the amount of flexibilty/interactivity it offers worth the cpu time.
Just not a good idea at all for front-end display during driving
sessions...

    Mickael Pointier

RE: [GD-General] Scaling GUI graphics

[Paul B. <pa...@mi...>]

We evaluated Flash for our gui/frontend.  The runtime
(we looked at an off the shelf flash renderer) was a=20
bit heavyweight for what we wanted, but one of the=20
guys here has an almost functional SVG renderer that=20
we might use in the future. =20

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]=20
> Sent: Tuesday, June 25, 2002 8:56 AM
> To: gam...@li...
> Subject: RE: [GD-General] Scaling GUI graphics
>=20
>=20
> The other cute trick I've heard of is to bite the bullet and=20
> put Flash in the game. Then the artists can do front ends and=20
> GUIs all they like, and the graphics coders don't have to be=20
> involved at all, so we can get on with the actual 3D stuff.=20
> Which appeals to me, seeing as the last fancy GUI we did=20
> chewed 6 months of a programmer's time. That was bad.
>=20
> Tom Forsyth - purely hypothetical Muckyfoot bloke.
>=20
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
>=20
> > -----Original Message-----
> > From: Kent Quirk [mailto:ken...@co...]
> > Sent: 25 June 2002 14:59
> > To: Tom Forsyth
> > Cc: Brian Hook; gam...@li...
> > Subject: Re: [GD-General] Scaling GUI graphics
> >=20
> >=20
> > We just built a skinnable GUI for a game we're doing. All=20
> the graphics=20
> > in the game are built from individual components at load time, with=20
> > the layout described in an XML file. We haven't supported=20
> any form of=20
> > scaling, as it's my experience that scaling always looks like hell.=20
> > But we do support tiling, so what we do is build a=20
> background texture=20
> > that's seamlessly tileable, and lay that down first. Then we place=20
> > interface elements on top of that.
> >=20
> > It let me use mixed file formats (highly compressed jpgs for the=20
> > background, GIFs for basic interface elements, and PNGs=20
> where I needed=20
> > transparency), and in addition to increased flexibility, we=20
> took about=20
> > 1.5 meg of interface graphics and compressed it to less than 300K.
> >=20
> >     Kent
> >=20
> >=20
> > Tuesday, June 25, 2002, 6:19:55 AM, you wrote:
> >=20
> > TF> My favourite solution is to scale, but only by powers of
> > two. So you design
> > TF> GUI graphics for 640x480. For 800x600 and 1024x768, you
> > don't scale, you
> > TF> just move them further apart (i.e. the bits stick to the
> > cornr, edge or
> > TF> centre as required). For 1280x1024 and above, you double
> > the size so that at
> > TF> least stuff is readable.
> >=20
> > TF> To do the scale x2 you can either just do the bilinear
> > filter thing (which
> > TF> doesn't look too bad on power-of-two scales), or just get
> > the artists to do
> > TF> second versions. Or mix'n'match (e.g. hand-done bigger
> > font, but scaled
> > TF> backgrounds).
> >=20
> > TF> Tom Forsyth - purely hypothetical Muckyfoot bloke.
> >=20
> > TF> This email is the product of your deranged imagination,=20
> and does=20
> > TF> not in any way imply existence of the author.
> >=20
> > >> -----Original Message-----
> > >> From: Brian Hook [mailto:bri...@py...]
> > >> Sent: 25 June 2002 04:23
> > >> To: gam...@li...
> > >> Subject: [GD-General] Scaling GUI graphics
> > >>=20
> > >>=20
> > >> Okay, this is a common problem that I'm sure others have
> > >> dealt with on=20
> > >> numerous occasions, but I have yet to deal with it so I'm=20
> > >> curious what the=20
> > >> conventional wisdom is.
> > >>=20
> > >> Basically it's the age old problem of having an interface
> > >> that looks good=20
> > >> at all resolutions.  AFAICT, the standards are:
> > >>=20
> > >> - do low res graphics for everything, then zoom appropriately
> > >> (leads to=20
> > >> serious blurring)
> > >>=20
> > >> - do multiple resolution graphics (lots of content)
> > >>=20
> > >> - render GUI graphics into textures/images instead of using
> > >> prefab images=20
> > >> (i.e. actually write line/circle/filled region software=20
> renderers)
> > >>=20
> > >> - don't scale, just make everything smaller (8x8 font at
> > >> 1600x1200...ewwww)
> > >>=20
> > >> Anyone find a solution that doesn't have a glaring flaw,
> > unlike the
> > >> above?  I suppose the closest I can think of is to do
> > >> everything in high=20
> > >> resolution, e.g. for a 1600x1200 interface, and then resample=20
> > >> down for=20
> > >> lower resolution displays.
> > >>=20
> > >> Brian
> > >>=20
> > >>=20
> > >>=20
> > >> -------------------------------------------------------
> > >> Sponsored by:
> > >> ThinkGeek at http://www.ThinkGeek.com/=20
> > >> _______________________________________________
> > >> Gamedevlists-general mailing list=20
> > >> Gam...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > >> Archives:=20
> http://sourceforge.net/mailarchive/forum.php?> forum_id=3D557
> > >>=20
> >=20
> >=20
> > TF> -------------------------------------------------------
> > TF> Sponsored by:
> > TF> ThinkGeek at http://www.ThinkGeek.com/
> > TF> _______________________________________________
> > TF> Gamedevlists-general mailing list
> > TF> Gam...@li...
> > TF>=20
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-gene
ral
> TF> Archives:
> TF> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20
>=20
> --=20
> Kent Quirk, CTO, CogniToy
> ken...@co...
> http://www.cognitoy.com
>=20


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

RE: [GD-General] Scaling GUI graphics

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

Interesting idea.

Any pointers to where to start looking ? We are doing an xbox game, so we
can't just link to flash or stuff like that.

What about the legality issues ?

-----Original Message-----
From: Tom Forsyth [mailto:to...@mu...]
Sent: 25 June 2002 14:56
To: gam...@li...
Subject: RE: [GD-General] Scaling GUI graphics


The other cute trick I've heard of is to bite the bullet and put Flash in
the game. Then the artists can do front ends and GUIs all they like, and the
graphics coders don't have to be involved at all, so we can get on with the
actual 3D stuff. Which appeals to me, seeing as the last fancy GUI we did
chewed 6 months of a programmer's time. That was bad.

Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Kent Quirk [mailto:ken...@co...]
> Sent: 25 June 2002 14:59
> To: Tom Forsyth
> Cc: Brian Hook; gam...@li...
> Subject: Re: [GD-General] Scaling GUI graphics
> 
> 
> We just built a skinnable GUI for a game we're doing. All the graphics
> in the game are built from individual components at load time, with
> the layout described in an XML file. We haven't supported any form of
> scaling, as it's my experience that scaling always looks like hell.
> But we do support tiling, so what we do is build a background texture
> that's seamlessly tileable, and lay that down first. Then we place
> interface elements on top of that.
> 
> It let me use mixed file formats (highly compressed jpgs for the
> background, GIFs for basic interface elements, and PNGs where I needed
> transparency), and in addition to increased flexibility, we took about
> 1.5 meg of interface graphics and compressed it to less than 300K.
> 
>     Kent
> 
> 
> Tuesday, June 25, 2002, 6:19:55 AM, you wrote:
> 
> TF> My favourite solution is to scale, but only by powers of 
> two. So you design
> TF> GUI graphics for 640x480. For 800x600 and 1024x768, you 
> don't scale, you
> TF> just move them further apart (i.e. the bits stick to the 
> cornr, edge or
> TF> centre as required). For 1280x1024 and above, you double 
> the size so that at
> TF> least stuff is readable.
> 
> TF> To do the scale x2 you can either just do the bilinear 
> filter thing (which
> TF> doesn't look too bad on power-of-two scales), or just get 
> the artists to do
> TF> second versions. Or mix'n'match (e.g. hand-done bigger 
> font, but scaled
> TF> backgrounds).
> 
> TF> Tom Forsyth - purely hypothetical Muckyfoot bloke.
> 
> TF> This email is the product of your deranged imagination,
> TF> and does not in any way imply existence of the author.
> 
> >> -----Original Message-----
> >> From: Brian Hook [mailto:bri...@py...]
> >> Sent: 25 June 2002 04:23
> >> To: gam...@li...
> >> Subject: [GD-General] Scaling GUI graphics
> >> 
> >> 
> >> Okay, this is a common problem that I'm sure others have 
> >> dealt with on 
> >> numerous occasions, but I have yet to deal with it so I'm 
> >> curious what the 
> >> conventional wisdom is.
> >> 
> >> Basically it's the age old problem of having an interface 
> >> that looks good 
> >> at all resolutions.  AFAICT, the standards are:
> >> 
> >> - do low res graphics for everything, then zoom appropriately 
> >> (leads to 
> >> serious blurring)
> >> 
> >> - do multiple resolution graphics (lots of content)
> >> 
> >> - render GUI graphics into textures/images instead of using 
> >> prefab images 
> >> (i.e. actually write line/circle/filled region software renderers)
> >> 
> >> - don't scale, just make everything smaller (8x8 font at 
> >> 1600x1200...ewwww)
> >> 
> >> Anyone find a solution that doesn't have a glaring flaw, 
> unlike the 
> >> above?  I suppose the closest I can think of is to do 
> >> everything in high 
> >> resolution, e.g. for a 1600x1200 interface, and then resample 
> >> down for 
> >> lower resolution displays.
> >> 
> >> Brian
> >> 
> >> 
> >> 
> >> -------------------------------------------------------
> >> Sponsored by:
> >> ThinkGeek at http://www.ThinkGeek.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
> >> 
> 
> 
> TF> -------------------------------------------------------
> TF> Sponsored by:
> TF> ThinkGeek at http://www.ThinkGeek.com/
> TF> _______________________________________________
> TF> Gamedevlists-general mailing list
> TF> Gam...@li...
> TF> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> TF> Archives:
> TF> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> 
> -- 
> Kent Quirk, CTO, CogniToy
> ken...@co...
> http://www.cognitoy.com
> 


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.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] Scaling GUI graphics

[brian h. <bri...@py...>]

> What about using a vector format for the graphics as apposed to a 
bitmap
> format ?

That's what I was thinking with the "render everything yourself" 
option (i.e. use circle, line, spline, etc. primitives and render into 
a bitmap yourself).  This isn't that bad, I suppose, but it does seem 
to be a bit of extra work.

> I've never tried this, but WMFs for example are very well 

Er, what's a WMF?

> For fonts just use proper ttf.

Is there a good open source library that can rasterize a TTF into a 
bitmap?  I know of SDL_ttf, but I'm not sure how good it is.

> If you insist on bitmap graphics

Well, there is that whole "texture maps are handy" bit ;)

-Hook

Re: [GD-General] Scaling GUI graphics

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

On Jun 25, 2002 at 10:04 -0500, brian hook wrote:

> > What about using a vector format for the graphics as apposed to a
> > bitmap format ?
> 
> That's what I was thinking with the "render everything yourself" 
> option (i.e. use circle, line, spline, etc. primitives and render into 
> a bitmap yourself).  This isn't that bad, I suppose, but it does seem 
> to be a bit of extra work.

Note: you don't have to render into a bitmap -- you could render
directly using OpenGL/D3D.  Dunno if you're already assuming a 3D API
though.

> Is there a good open source library that can rasterize a TTF into a 
> bitmap?  I know of SDL_ttf, but I'm not sure how good it is.

FreeType (http://www.freetype.org) makes high quality output; it's
what XFree86 uses these days.  I bet it's what SDL_ttf uses, but I'm
not sure.

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] Scaling GUI graphics

[brian h. <bri...@py...>]

> My favourite solution is to scale, but only by powers of two. So you 
design
> GUI graphics for 640x480. For 800x600 and 1024x768, you don't scale, 
you
> just move them further apart (i.e. the bits stick to the cornr, edge 
or
> centre as required). For 1280x1024 and above, you double the size so 
that at
> least stuff is readable.
 
Doesn't this have the rather unintuitive property that usable space 
actually drops every N resolutions?  So you have more usable space at 
1024x768 than at 1280x1024?  Or is that under "acceptable compromise"? 
=)

-Hook

RE: [GD-General] Scaling GUI graphics

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

> > I've never tried this, but WMFs for example are very well 

> Er, what's a WMF?

WMFs are Window Meta Files or something like that, you have WMF files if you
installed the graphics stuff that comes with MSDEV.

You will find info at http://www.wotsit.org and in MSDN (OleLoadPicture is a
good place to start)


> > For fonts just use proper ttf.

> Is there a good open source library that can rasterize a TTF into a 
> bitmap?  I know of SDL_ttf, but I'm not sure how good it is.

There is lots of ttf stuff, at the least you can just use GDI to rasterize
the alphabet to a surface and use that for font stuff.

RTFM about GetCharABCWidths() and DrawText() to do proper mapping.

We use this stuff to create our bitmapped fonts, and it allows us to get the
correct kerning(sp?) and stuff for all letters, so our bitmapped fonts look
as good as ttfs do in windows.


> > If you insist on bitmap graphics

> Well, there is that whole "texture maps are handy" bit ;)

Well I never said you wouldn't have bitmaps at the _END_ (i.e. before you
draw) I meant pre-made bitmap graphics.

___________________
Regards, Gareth Lewin

RE: [GD-General] Scaling GUI graphics

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

Depends what you mean by "usable space". I would assert that for a game, you
want everyone to have the same usable space as everyone else, regardless of
resolution, i.e. they have the same field of view, etc. Otherwise
multiplayer games are unfair, and/or it will be hard to balance the
single-player game. If the game is hard to play in 640x480, then that's not
friendly to the lower-end of the market. If it's easier to play in high
resolutions, then you're not going to entertain the hard-core. If there's no
difference in gameplay, then - er - what did you need the usable space for
again? (I'm not explaining this very clearly - sorry).

So higher res should really only mean the game looks better, it shouldn't
change anything about how it plays.

In StarTopia, we dodged the bullet by only allowing one window open at a
time (er... except for a bug we found post-ship), and everything fitted on a
640x480 screen, so greater screen space didn't help at all. Which meant we
didn't bother scaling in the end (though we did think about it). We did
still get complaints that the text was too small to read in the higher
resolutions, so we probably should have put scaling in.

Tom Forsyth - purely hypothetical Muckyfoot bloke.

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:bri...@py...]
> Sent: 25 June 2002 16:10
> To: gam...@li...
> Subject: RE: [GD-General] Scaling GUI graphics
> 
> 
> 
> 
> > My favourite solution is to scale, but only by powers of 
> two. So you 
> design
> > GUI graphics for 640x480. For 800x600 and 1024x768, you 
> don't scale, 
> you
> > just move them further apart (i.e. the bits stick to the 
> cornr, edge 
> or
> > centre as required). For 1280x1024 and above, you double 
> the size so 
> that at
> > least stuff is readable.
>  
> Doesn't this have the rather unintuitive property that usable space 
> actually drops every N resolutions?  So you have more usable space at 
> 1024x768 than at 1280x1024?  Or is that under "acceptable 
> compromise"? 
> =)
> 
> -Hook
> 
> 
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.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] Scaling GUI graphics

[brian h. <bri...@py...>]

> Depends what you mean by "usable space". I would assert that for a 
game, you
> want everyone to have the same usable space as everyone else, 
regardless of
> resolution, i.e. they have the same field of view, etc. Otherwise
> multiplayer games are unfair, and/or it will be hard to balance the
> single-player game. 

There's a difference between convenience and difficulty.  I agree that 
the game should be equally viable in 640x480 and 1600x1200, however 
there are some things that make a game more pleasing to play that might 
be available if you have more room in the interface.  The obvious 
example are chat windows in a multiplayer game.  They might give you a 
slight competitive advantage, but the real advantage is that you don't 
have a clutter of overlapping chat windows while you're trying to talk 
to your mates in the guild, in the store, and a couple private 
conversations at once.

-Hook

Re: [GD-General] Scaling GUI graphics

[brian h. <bri...@py...>]

> Note: you don't have to render into a bitmap -- you could render
> directly using OpenGL/D3D.  Dunno if you're already assuming a 3D API
> though.

Did you mean glLine/glPoint calls?

> FreeType (http://www.freetype.org) makes high quality output; it's
> what XFree86 uses these days.

Cool, I'll check it out, thanks.

I use that one would need a freely redistributable TTF fonts (are the 
Windows ones in the free and clear?  I doubt it).

-Hook

Re: [GD-General] Scaling GUI graphics

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

On Jun 25, 2002 at 11:09 -0500, brian hook wrote:
> > Note: you don't have to render into a bitmap -- you could render
> > directly using OpenGL/D3D.  Dunno if you're already assuming a 3D API
> > though.
> 
> Did you mean glLine/glPoint calls?

Not sure what glLine is, but yeah,
glBegin(GL_{POINTS,LINES,LINE_STRIP,LINE_LOOP}) or whatever.  Or use
artist-painted UI elements, and scale/tile them using triangles/quads
(that's what we did in Soul Ride).

> > FreeType (http://www.freetype.org) makes high quality output; it's
> > what XFree86 uses these days.
> 
> Cool, I'll check it out, thanks.
> 
> I use that one would need a freely redistributable TTF fonts (are the 
> Windows ones in the free and clear?  I doubt it).

Heh, I think you're right.  MS's web fonts are good quality and free
as in beer, but I imagine there are limits on redistribution.  Debian
Linux actually includes a package that downloads the fonts from MS's
web site and installs them, so the fonts themselves aren't actually in
the distro.  That's probably too complicated an approach to rely on
for a mass market game though.

What we did in Soul Ride, which worked well I think, was the artist
made antialiased bitmapped fonts in Photoshop (from TrueType source
fonts), and we rendered using alpha blending.  Scaling worked fine;
the antialiasing will obviously work better if you don't scale too
radically, but over a factor of 2 or 3x, they looked pretty nice IMO.

The MS fonts are the only scalable fonts that don't look like total
crap on my Linux box, so I suspect you won't find good free hinted TT
fonts.  Although antialiasing would help.

One of my super back-burner projects is a public domain Flash
parser/renderer.

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] Scaling GUI graphics

[Brian S. <bs...@mi...>]

for open source font rendering check out http://www.freetype.org/

for flash check out http://www.openswf.org/

--brian

> -----Original Message-----
> From: brian hook [mailto:bri...@py...]=20
> Sent: Tuesday, June 25, 2002 8:05 AM
> To: gam...@li...
> Subject: RE: [GD-General] Scaling GUI graphics
>=20
>=20
> > What about using a vector format for the graphics as apposed to a=20
> bitmap
> > format ?
>=20
> That's what I was thinking with the "render everything yourself"=20
> option (i.e. use circle, line, spline, etc. primitives and=20
> render into=20
> a bitmap yourself).  This isn't that bad, I suppose, but it does seem=20
> to be a bit of extra work.
>=20
> > I've never tried this, but WMFs for example are very well=20
>=20
> Er, what's a WMF?
>=20
> > For fonts just use proper ttf.
>=20
> Is there a good open source library that can rasterize a TTF into a=20
> bitmap?  I know of SDL_ttf, but I'm not sure how good it is.
>=20
> > If you insist on bitmap graphics
>=20
> Well, there is that whole "texture maps are handy" bit ;)
>=20
> -Hook

RE: [GD-General] Scaling GUI graphics

[Brian S. <bs...@mi...>]

> > > FreeType (http://www.freetype.org) makes high quality output; it's
> > > what XFree86 uses these days.
> >=20
> > Cool, I'll check it out, thanks.
> >=20
> > I use that one would need a freely redistributable TTF=20
> fonts (are the=20
> > Windows ones in the free and clear?  I doubt it).
>=20
> Heh, I think you're right.  MS's web fonts are good quality and free
> as in beer, but I imagine there are limits on redistribution.  Debian
> Linux actually includes a package that downloads the fonts from MS's
> web site and installs them, so the fonts themselves aren't actually in
> the distro.  That's probably too complicated an approach to rely on
> for a mass market game though.
>=20
> What we did in Soul Ride, which worked well I think, was the artist
> made antialiased bitmapped fonts in Photoshop (from TrueType source
> fonts), and we rendered using alpha blending.  Scaling worked fine;
> the antialiasing will obviously work better if you don't scale too
> radically, but over a factor of 2 or 3x, they looked pretty nice IMO.

I've done this in the past too, and it looks pretty good.  The downside
is that if you just render a string by rendering individual characters,
you don't get nice things like pair kerning and ligature substitution
that make your text look really high-quality...still, for the average
game that's overkill.

I'm ignorant of the legal issues involved, but it seems like it should
be technically possible to process a TTF font into a bitmap font via
freetype and end up with something that you can use in your game...

--brian

Re: [GD-General] Scaling GUI graphics

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

On Jun 25, 2002 at 12:02 -0700, Brian Sharon wrote:
> 
> I'm ignorant of the legal issues involved, but it seems like it should
> be technically possible to process a TTF font into a bitmap font via
> freetype and end up with something that you can use in your game...

If I'm not mistaken, bitmap images of fonts are not copyrightable.
I.e. the ttf files are copyrighted, but you can do whatever you want
with any images you make by rendering text using that font.

IANAL though...

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] Scaling GUI graphics

[Corrinne Y. <cor...@el...>]

Another possible easy option is to do the interface in 3D, especially if
you are running the GUI over a 3D engine anyway.

RE: [GD-General] Scaling GUI graphics

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

We do all our front-end / HUD stuff in Flash, although our scripting
support is limited to Flash 4, and there's a couple of rendering things we
don't do, either for performance, or 'bang for buck' issues. IIRC some of
our game logic was in it for a while (I certainly recall having to read
state changes back out of the flash interface class).

We're doing this for authoring reasons, rather than re-sizing issues
though. Closest we get to resolution changes are supporting 4:3 / 16:9 and
PAL / NTSC.

Cheers,
Phil

PS I'd like to point out that we did use flash during run-time, and still
maintained a solid 60 fps.



                                                                                                                                  
                    "Paul Bleisch" <pa...@mi...>                                                                        
                    Sent by:                                     To:     <gam...@li...>             
                    gam...@li...urc       cc:                                                              
                    eforge.net                                   Subject:     RE: [GD-General] Scaling GUI graphics               
                                                                                                                                  
                                                                                                                                  
                    06/25/2002 07:10 AM                                                                                           
                                                                                                                                  
                                                                                                                                  





We evaluated Flash for our gui/frontend.  The runtime
(we looked at an off the shelf flash renderer) was a
bit heavyweight for what we wanted, but one of the
guys here has an almost functional SVG renderer that
we might use in the future.

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: Tuesday, June 25, 2002 8:56 AM
> To: gam...@li...
> Subject: RE: [GD-General] Scaling GUI graphics
>
>
> The other cute trick I've heard of is to bite the bullet and
> put Flash in the game. Then the artists can do front ends and
> GUIs all they like, and the graphics coders don't have to be
> involved at all, so we can get on with the actual 3D stuff.
> Which appeals to me, seeing as the last fancy GUI we did
> chewed 6 months of a programmer's time. That was bad.
>
> Tom Forsyth - purely hypothetical Muckyfoot bloke.
>
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
>
> > -----Original Message-----
> > From: Kent Quirk [mailto:ken...@co...]
> > Sent: 25 June 2002 14:59
> > To: Tom Forsyth
> > Cc: Brian Hook; gam...@li...
> > Subject: Re: [GD-General] Scaling GUI graphics
> >
> >
> > We just built a skinnable GUI for a game we're doing. All
> the graphics
> > in the game are built from individual components at load time, with
> > the layout described in an XML file. We haven't supported
> any form of
> > scaling, as it's my experience that scaling always looks like hell.
> > But we do support tiling, so what we do is build a
> background texture
> > that's seamlessly tileable, and lay that down first. Then we place
> > interface elements on top of that.
> >
> > It let me use mixed file formats (highly compressed jpgs for the
> > background, GIFs for basic interface elements, and PNGs
> where I needed
> > transparency), and in addition to increased flexibility, we
> took about
> > 1.5 meg of interface graphics and compressed it to less than 300K.
> >
> >     Kent
> >
> >
> > Tuesday, June 25, 2002, 6:19:55 AM, you wrote:
> >
> > TF> My favourite solution is to scale, but only by powers of
> > two. So you design
> > TF> GUI graphics for 640x480. For 800x600 and 1024x768, you
> > don't scale, you
> > TF> just move them further apart (i.e. the bits stick to the
> > cornr, edge or
> > TF> centre as required). For 1280x1024 and above, you double
> > the size so that at
> > TF> least stuff is readable.
> >
> > TF> To do the scale x2 you can either just do the bilinear
> > filter thing (which
> > TF> doesn't look too bad on power-of-two scales), or just get
> > the artists to do
> > TF> second versions. Or mix'n'match (e.g. hand-done bigger
> > font, but scaled
> > TF> backgrounds).
> >
> > TF> Tom Forsyth - purely hypothetical Muckyfoot bloke.
> >
> > TF> This email is the product of your deranged imagination,
> and does
> > TF> not in any way imply existence of the author.
> >
> > >> -----Original Message-----
> > >> From: Brian Hook [mailto:bri...@py...]
> > >> Sent: 25 June 2002 04:23
> > >> To: gam...@li...
> > >> Subject: [GD-General] Scaling GUI graphics
> > >>
> > >>
> > >> Okay, this is a common problem that I'm sure others have
> > >> dealt with on
> > >> numerous occasions, but I have yet to deal with it so I'm
> > >> curious what the
> > >> conventional wisdom is.
> > >>
> > >> Basically it's the age old problem of having an interface
> > >> that looks good
> > >> at all resolutions.  AFAICT, the standards are:
> > >>
> > >> - do low res graphics for everything, then zoom appropriately
> > >> (leads to
> > >> serious blurring)
> > >>
> > >> - do multiple resolution graphics (lots of content)
> > >>
> > >> - render GUI graphics into textures/images instead of using
> > >> prefab images
> > >> (i.e. actually write line/circle/filled region software
> renderers)
> > >>
> > >> - don't scale, just make everything smaller (8x8 font at
> > >> 1600x1200...ewwww)
> > >>
> > >> Anyone find a solution that doesn't have a glaring flaw,
> > unlike the
> > >> above?  I suppose the closest I can think of is to do
> > >> everything in high
> > >> resolution, e.g. for a 1600x1200 interface, and then resample
> > >> down for
> > >> lower resolution displays.
> > >>
> > >> Brian
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------
> > >> Sponsored by:
> > >> ThinkGeek at http://www.ThinkGeek.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
> > >>
> >
> >
> > TF> -------------------------------------------------------
> > TF> Sponsored by:
> > TF> ThinkGeek at http://www.ThinkGeek.com/
> > TF> _______________________________________________
> > TF> Gamedevlists-general mailing list
> > TF> Gam...@li...
> > TF>
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-gene
ral
> TF> Archives:
> TF> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>
> --
> Kent Quirk, CTO, CogniToy
> ken...@co...
> http://www.cognitoy.com
>


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.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


-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
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] Scaling GUI graphics

[Corrinne Y. <cor...@el...>]

We do all our front-end / HUD stuff in Flash, although our scripting
support is limited to Flash 4, and there's a couple of rendering things
we
don't do, either for performance, or 'bang for buck' issues. IIRC some
of
our game logic was in it for a while (I certainly recall having to read
state changes back out of the flash interface class).

We're doing this for authoring reasons, rather than re-sizing issues
though. Closest we get to resolution changes are supporting 4:3 / 16:9
and
PAL / NTSC.

-- This sounds kind of interesting. Do you read the raw Flash 4 file
output and implement the entire Flash 4 API?

-- Is Flash 4 a text or binary file format? I apologize for being a
Flash neophyte. Do you parse the text or the binary, and where does one
find a script and API reference to Flash 4 (if one has never used it
before)?

-- It really depends how thick the API is whether it may be too heavy
weight in our case to implement as a GUI displayer.

-- Thank you for your help.

Re: [GD-General] Scaling GUI graphics

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

On Aug 20, 2002 at 08:53 -0500, Corrinne Yu wrote:
> 
> We do all our front-end / HUD stuff in Flash, although our scripting
> support is limited to Flash 4, and there's a couple of rendering things
> we
> don't do, either for performance, or 'bang for buck' issues. IIRC some
> of
> our game logic was in it for a while (I certainly recall having to read
> state changes back out of the flash interface class).
> 
> We're doing this for authoring reasons, rather than re-sizing issues
> though. Closest we get to resolution changes are supporting 4:3 / 16:9
> and
> PAL / NTSC.
> 
> -- This sounds kind of interesting. Do you read the raw Flash 4 file
> output and implement the entire Flash 4 API?

I'm also interested in details...

> -- Is Flash 4 a text or binary file format? I apologize for being a
> Flash neophyte. Do you parse the text or the binary, and where does one
> find a script and API reference to Flash 4 (if one has never used it
> before)?

see http://www.openswf.org -- swf is a packed binary format, actually
very clever IMO.  There's some GPL code, and apparently you may be
able to license code from Macromedia.  I keep threatening to write a
public domain SWF library, but it's mostly vapor at the moment.

> -- It really depends how thick the API is whether it may be too heavy
> weight in our case to implement as a GUI displayer.

The shape display is oriented around curved outlines, and definitely
has the look of something that wants to use an antialiased scanline
renderer.  But it definitely seems possible to do an OpenGL or D3D
implementation.

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] Scaling GUI graphics

[brian h. <bri...@py...>]

This doesn't really help, since you're still limited by texture size.  
The key is whether you're going to scale your graphics or not to meet 
the screen res.  If you do scale it up, then you're effectively dealing 
with a fixed resolution GUI (not necessarily bad, just doesn't take 
advantage of the increased resolution to provide either higher 
resolution or more usable area).

> Another possible easy option is to do the interface in 3D, especially 
if
> you are running the GUI over a 3D engine anyway.

RE: [GD-General] Scaling GUI graphics

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

Err, I reckon it probably took Bob a month of core programming, plus
ongoing support and maintanence. He's still tweaking and optimising it, as
there's always something to improve (currently it's the text rendering).

I believe it's a binary format, but one that's well documented (I'd ask
Bob, but he's on holiday at the moment, I myself would have replied
earlier, but I've just come back from honeymoon;). The main saving was one
of not having to write the front end editor, although obviously we still
had to write all the hooks.

Communication between the flash interpreter and the game code is a bit
hairy, but boils down to shared memory. The flash does all the menu logic,
setting state variables which the game code polls. This meant that our
flash designer/artist/programmer (he's a flexible guy) could try different
layouts and structures without hassling the programmers too much.

It was most definately worth the initial hassle, especially since we're
re-using all the code for our current project. The only thing that worries
me is relying on an old version of the macromedia tools to enforce our
restrictions. Hopefully if more people start using it, Macromedia will take
note.

As to rendering, everything is converted into tristrips, in a pre-process.
I believe we can control anti-aliasing on a per-object basis, although we
may have had to remove it for certain primitives. I think there were issues
with spider-webbing on translucent objects.

Cheers,
Phil



                                                                                                                       
                    "Corrinne Yu"                                                                                      
                    <corrinne@elapsesof       To:     <phi...@pl...>                              
                    tware.com>                cc:                                                                      
                                              Subject:     RE: [GD-General] Scaling GUI graphics                       
                    08/19/2002 06:35 PM                                                                                
                    Please respond to                                                                                  
                    corrinne                                                                                           
                                                                                                                       
                                                                                                                       




-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
phi...@pl...
Sent: Tuesday, June 25, 2002 2:40 PM
To: gam...@li...
Subject: RE: [GD-General] Scaling GUI graphics


We do all our front-end / HUD stuff in Flash, although our scripting
support is limited to Flash 4, and there's a couple of rendering things
we
don't do, either for performance, or 'bang for buck' issues. IIRC some
of
our game logic was in it for a while (I certainly recall having to read
state changes back out of the flash interface class).

-- Cool. How long did it take you? (And was it worth it time wise?)

-- Did you read Flash 4 file format? Is it a text or binary file? It is
kind of cool because you saved programming time of programming the GUI
and programming time of programming a GUI editor (which very few
programmers make anyway).

RE: [GD-General] Scaling GUI graphics

[Phil T. <ph...@mi...>]

The file format is publicly available at macromedia:

http://www.macromedia.com/software/flash/open/licensing/fileformat/

I believe there are some errors in the documentation; however, there are
some corrections floating around on the web (once again google is your
friend here).

Phil

-----Original Message-----
From: phi...@pl...
[mailto:phi...@pl...]=20
Sent: Monday, August 26, 2002 1:53 PM
To: cor...@el...
Cc: gam...@li...
Subject: RE: [GD-General] Scaling GUI graphics


Err, I reckon it probably took Bob a month of core programming, plus
ongoing support and maintanence. He's still tweaking and optimising it,
as
there's always something to improve (currently it's the text rendering).

I believe it's a binary format, but one that's well documented (I'd ask
Bob, but he's on holiday at the moment, I myself would have replied
earlier, but I've just come back from honeymoon;). The main saving was
one
of not having to write the front end editor, although obviously we still
had to write all the hooks.

Communication between the flash interpreter and the game code is a bit
hairy, but boils down to shared memory. The flash does all the menu
logic,
setting state variables which the game code polls. This meant that our
flash designer/artist/programmer (he's a flexible guy) could try
different
layouts and structures without hassling the programmers too much.

It was most definately worth the initial hassle, especially since we're
re-using all the code for our current project. The only thing that
worries
me is relying on an old version of the macromedia tools to enforce our
restrictions. Hopefully if more people start using it, Macromedia will
take
note.

As to rendering, everything is converted into tristrips, in a
pre-process.
I believe we can control anti-aliasing on a per-object basis, although
we
may have had to remove it for certain primitives. I think there were
issues
with spider-webbing on translucent objects.

Cheers,
Phil



=20

                    "Corrinne Yu"

                    <corrinne@elapsesof       To:
<phi...@pl...>                             =20
                    tware.com>                cc:

                                              Subject:     RE:
[GD-General] Scaling GUI graphics                      =20
                    08/19/2002 06:35 PM

                    Please respond to

                    corrinne

=20

=20





-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
phi...@pl...
Sent: Tuesday, June 25, 2002 2:40 PM
To: gam...@li...
Subject: RE: [GD-General] Scaling GUI graphics


We do all our front-end / HUD stuff in Flash, although our scripting
support is limited to Flash 4, and there's a couple of rendering things
we
don't do, either for performance, or 'bang for buck' issues. IIRC some
of
our game logic was in it for a while (I certainly recall having to read
state changes back out of the flash interface class).

-- Cool. How long did it take you? (And was it worth it time wise?)

-- Did you read Flash 4 file format? Is it a text or binary file? It is
kind of cool because you saved programming time of programming the GUI
and programming time of programming a GUI editor (which very few
programmers make anyway).







-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557