gamedevlists-general — List for discussing general game development issues

Re: [GD-General] GUI Design

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

On Thu, 23 Jan 2003 10:51:36 +0000
Jamie Fowlston <ja...@qu...> wrote:

> our engine lets the user specify a virtual coordinate system within which
> they can work, independently of the actual display resolution. works fine :)
> 
> what you do as regards multiple monitors and positioning / scaling
> components within that virtual space is up to you :)

How does that work for varying aspect ratios? If the designer creates a
GUI with a certain aspect ratio in mind, and then you switch to HDTV
mode, are components rearranged correctly?

I'm thinking more along the lines of those Java-style layouts, that way
they can put a left box with a bunch of stuff inside, a bottom box, etc.
Then changing the screen ratio would make everything work perfectly.


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

RE: [GD-General] GUI Design

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

We use a virtual resolution of 640x480, because it's easier for people to
grok than 0-1. Also, it's easy to make sure stuff is at least roughly
square. Then whether the actual rez is 640x448 or 800x600 or whatever, it's
all scaled accordingly.

It's zero cost for the GPU to rescale that to whatever coordinates it wants
- you just wrap it up in the projection matrix.


For GUIs with lots of text, it may be better to work in screen space, but
have each part of GUI "seek" towards a particular corner or edge (middle-top
of screen for example). So when giving coordinates in 640x480 space, you
always say which of the 9 (including the middle of the screen) positions its
relative to. Then the position ad size doesn't get scaled, it stays the same
size and moves along with its reference point.


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: Jason Maynard [mailto:jma...@li...]
> Sent: 23 January 2003 00:46
> To: gam...@li...
> Subject: Re: [GD-General] GUI Design
> 
> 
> 
> Yeah I would recommend using values between 0.0 and 1.0 as a 
> percentage of
> the width or height of the screen like you said, you can 
> convert to actual
> screen coordinates by just multiplying the the screen width 
> or height then.
> 
> Another option is to design the GUI layout in a fixed 
> resolution and then to
> convert them into a different resolution apply a scaling 
> factor.  Say you
> have a point (x,y) in 640x480 layout and your screen is in 
> resolution WxH,
> then to find the point (x',y') in screen space:
> 
> x' = x * (W / 640);
> y' = y * (H / 480);
> 
> -Jason
> 
> ----- Original Message -----
> From: "Chris Brodie" <Chr...@ma...>
> To: <gam...@li...>
> Sent: Wednesday, January 22, 2003 4:14 PM
> Subject: [GD-General] GUI Design
> 
> 
> > I've been building a GUI for my game but from day 1 have 
> had a design
> issue I've been ignoring. From the beginning I've coded the coordinate
> system to OpenGL's bottom left origin. This is a minor pain 
> as I'm the only
> one who needs to worry about the coordinates in the menu xml 
> files (for
> now).
> >
> > The problem however is when I resize the screen everything remains
> squished in the bottom left corner of the screen. The only ay 
> I can think of
> solving the problem so it looks 'normal' is to provide some 
> kind of virtual
> scaling system that the menu is designed against that is then 
> translated in
> to screen coordinates. For example I could use something 
> simple like 100%
> equalling the width of the screen, so a box might be 20% wide 
> 15% high at
> position 5%,5%.
> >
> > How have you guys solved this problem? My solution 
> presented seems like
> it'll add a whole lot more math to the GUI to do all the 
> translations for
> the virtual screen space.
> >
> > Thoughts?
> >
> > Chris Brodie
> >
> >
> > NOTICE
> > This e-mail and any attachments are confidential and may 
> contain copyright
> material of Macquarie Bank or third parties. If you are not 
> the intended
> recipient of this email you should not read, print, 
> re-transmit, store or
> act in reliance on this e-mail or any attachments, and should 
> destroy all
> copies of them. Macquarie Bank does not guarantee the integrity of any
> emails or any attached files. The views or opinions expressed are the
> author's own and may not reflect the views or opinions of 
> Macquarie Bank.
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Scholarships for Techies!
> > Can't afford IT training? All 2003 ictp students receive 
> scholarships.
> > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, 
> and more.
> > www.ictp.com/training/sourceforge.asp
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> 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] GUI Design

[Jamie F. <ja...@qu...>]

our engine lets the user specify a virtual coordinate system within which
they can work, independently of the actual display resolution. works fine :)

what you do as regards multiple monitors and positioning / scaling
components within that virtual space is up to you :)

j


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Chris Brodie
Sent: 23 January 2003 00:14
To: 'gam...@li...'
Subject: [GD-General] GUI Design


I've been building a GUI for my game but from day 1 have had a design issue
I've been ignoring. From the beginning I've coded the coordinate system to
OpenGL's bottom left origin. This is a minor pain as I'm the only one who
needs to worry about the coordinates in the menu xml files (for now).

The problem however is when I resize the screen everything remains squished
in the bottom left corner of the screen. The only ay I can think of solving
the problem so it looks 'normal' is to provide some kind of virtual scaling
system that the menu is designed against that is then translated in to
screen coordinates. For example I could use something simple like 100%
equalling the width of the screen, so a box might be 20% wide 15% high at
position 5%,5%.

How have you guys solved this problem? My solution presented seems like
it'll add a whole lot more math to the GUI to do all the translations for
the virtual screen space.

Thoughts?

Chris Brodie


NOTICE
This e-mail and any attachments are confidential and may contain copyright
material of Macquarie Bank or third parties. If you are not the intended
recipient of this email you should not read, print, re-transmit, store or
act in reliance on this e-mail or any attachments, and should destroy all
copies of them. Macquarie Bank does not guarantee the integrity of any
emails or any attached files. The views or opinions expressed are the
author's own and may not reflect the views or opinions of Macquarie Bank.



-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
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] GUI Design

[Troy G. <Tr...@cs...>]

The only problem I have with percentages relates to this, but not directly.
The main issue to me is that a 0.0 -> 1.0 mapping in X and Y implies a 1:1
aspect ratio to the screen, *or* it implies non-square pixels (neither of
which is true). While this may not present any problems in a practical
sense, it would certainly present issues (as mentioned before) for
pixel-perfect kind of presentation.

I would do something along the lines of this: define the world as a 1024x768
screen. 1024 is the resolution of units in alot of packages (IIRC Flash
divides pixels into 1024 fractions for position vectors). 1024x768 is, I
would imagine, a *very* common display resolution for games (it's my current
favorite as a sweet spot between good resolution but not too high). And, it
represents the 4:3 aspect ratio that would be present in 640x480, 800x600,
1280x1024 (well, not exactly), 1600x1200... And, if you wanted to be really
cool, then you'd do a *separate* layout for 16x9 displays (or just float the
1024x768 horizontally centered with texturing to fill the sides).

In the case of tri-head stuff (or dual-head), I would recommend explicitly
checking for those situations and either supporting or not specifically. I
would *not* try to come up with a form of units that fits *all* cases,
because as mentioned below you'll get stretching (or you won't end up using
the screen real estate effectively).

That being said, are there any games out there that take advantage of
dual-monitor/dual-head/tri-head video cards? I know the ole Doom would allow
you to run up a network client on three different machines and each machine
could be linked for a panoramic view... it'd probably be just 0.01% of the
gaming population, but it'd certain be cool (imagine an RTS spanning threee
monitors...).

Troy
Developer Relations
Criterion Software
www.csl.com


> -----Original Message-----
> From: Ray [mailto:ra...@gu...]
> Sent: Wednesday, January 22, 2003 7:54 PM
> To: gam...@li...
> Subject: Re: [GD-General] GUI Design
> 
> 
> Make sure you take window aspect into account.
> For example, if you're in parhelia triple-headed mode, your 
> aspect is really wide and you don't want things horribly stretched.
> 
> - Ray
> 
> Jason Maynard wrote:
> > Yeah I would recommend using values between 0.0 and 1.0 as 
> a percentage of
> > the width or height of the screen like you said, you can 
> convert to actual
> > screen coordinates by just multiplying the the screen width 
> or height then.
> > 
> > Another option is to design the GUI layout in a fixed 
> resolution and then to
> > convert them into a different resolution apply a scaling 
> factor.  Say you
> > have a point (x,y) in 640x480 layout and your screen is in 
> resolution WxH,
> > then to find the point (x',y') in screen space:
> > 
> > x' = x * (W / 640);
> > y' = y * (H / 480);
> > 
> > -Jason
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> 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] GUI Design

[Ray <ra...@gu...>]

Make sure you take window aspect into account.
For example, if you're in parhelia triple-headed mode, your aspect is really wide and you don't want things horribly stretched.

- Ray

Jason Maynard wrote:
> Yeah I would recommend using values between 0.0 and 1.0 as a percentage of
> the width or height of the screen like you said, you can convert to actual
> screen coordinates by just multiplying the the screen width or height then.
> 
> Another option is to design the GUI layout in a fixed resolution and then to
> convert them into a different resolution apply a scaling factor.  Say you
> have a point (x,y) in 640x480 layout and your screen is in resolution WxH,
> then to find the point (x',y') in screen space:
> 
> x' = x * (W / 640);
> y' = y * (H / 480);
> 
> -Jason

Re: [GD-General] GUI Design

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

On Thu, 23 Jan 2003 11:14:03 +1100, Chris Brodie wrote:

>think of solving the problem so it looks 'normal' is to provide=
 some
>kind of virtual scaling system that the menu is designed=
 against
>that is then translated in to screen coordinates. 

The NextStep Interface Builder handled this in a fairly elegant 
manner using "bars and springs".  In the GUI designer you could 
specify a GUI widget as being tied to another either using a bar=
 or a 
spring.

A bar would always keep that component a fixed distance from an=
 edge. 
 For example, if you wanted to have a row of buttons aligned on=
 the 
right hand side of a resizable window.

Springs, as you would guess, stretch to fit.  This is how you=
 would 
specify, say, a button that is always centered.  Each side of a 
widget could have a bar or a spring, so you could have something=
 that 
was always centered horizontally but always a fixed distance from=
 the 
top edge of the parent component, etc.

>For example I
>could use something simple like 100% equalling the width of the
>screen, so a box might be 20% wide 15% high at position 5%,5%.

That's the typical fashion.  The downside is that you give up=
 precise 
measurements and it just feels a little "weird" to many people. =
 And, 
of course, there's the whole issue of scaling GUI graphics,=
 period.

Another compromise is to work in some idealized screen resolution=
 
that you don't plan on exceeding, like 1600x1200, and then scale=
 down 
from there.  That way your designers are always working in pixel=
 
units instead of percentages.

>How have you guys solved this problem? My solution presented=
 seems
>like it'll add a whole lot more math to the GUI to do all the
>translations for the virtual screen space.]

That amount of math should be relatively trivial though in the=
 grand 
scheme of things.

-Hook

Re: [GD-General] GUI Design

[Jason M. <jma...@li...>]

Yeah I would recommend using values between 0.0 and 1.0 as a percentage of
the width or height of the screen like you said, you can convert to actual
screen coordinates by just multiplying the the screen width or height then.

Another option is to design the GUI layout in a fixed resolution and then to
convert them into a different resolution apply a scaling factor.  Say you
have a point (x,y) in 640x480 layout and your screen is in resolution WxH,
then to find the point (x',y') in screen space:

x' = x * (W / 640);
y' = y * (H / 480);

-Jason

----- Original Message -----
From: "Chris Brodie" <Chr...@ma...>
To: <gam...@li...>
Sent: Wednesday, January 22, 2003 4:14 PM
Subject: [GD-General] GUI Design


> I've been building a GUI for my game but from day 1 have had a design
issue I've been ignoring. From the beginning I've coded the coordinate
system to OpenGL's bottom left origin. This is a minor pain as I'm the only
one who needs to worry about the coordinates in the menu xml files (for
now).
>
> The problem however is when I resize the screen everything remains
squished in the bottom left corner of the screen. The only ay I can think of
solving the problem so it looks 'normal' is to provide some kind of virtual
scaling system that the menu is designed against that is then translated in
to screen coordinates. For example I could use something simple like 100%
equalling the width of the screen, so a box might be 20% wide 15% high at
position 5%,5%.
>
> How have you guys solved this problem? My solution presented seems like
it'll add a whole lot more math to the GUI to do all the translations for
the virtual screen space.
>
> Thoughts?
>
> Chris Brodie
>
>
> NOTICE
> This e-mail and any attachments are confidential and may contain copyright
material of Macquarie Bank or third parties. If you are not the intended
recipient of this email you should not read, print, re-transmit, store or
act in reliance on this e-mail or any attachments, and should destroy all
copies of them. Macquarie Bank does not guarantee the integrity of any
emails or any attached files. The views or opinions expressed are the
author's own and may not reflect the views or opinions of Macquarie Bank.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> 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] GUI Design

[Jones, C. <CJ...@bl...>]

You could just choose a fixed resolution for layout, and scale to the
resolution you are running in.  This is what I did and it worked out fine.
It is similar to what you are suggesting, just looking at it from a
different angle.  All layout for our GUI is done as if the game runs at a
fixed 800x600 resolution.  Any time the resolution changes during game play
(including at startup), the GUI is told to adjust it's x/y scaling factors
accordingly.

Chris
 
-----Original Message-----
From: Chris Brodie [mailto:Chr...@ma...] 
Sent: Wednesday, January 22, 2003 4:14 PM
To: 'gam...@li...'
Subject: [GD-General] GUI Design

I've been building a GUI for my game but from day 1 have had a design issue
I've been ignoring. From the beginning I've coded the coordinate system to
OpenGL's bottom left origin. This is a minor pain as I'm the only one who
needs to worry about the coordinates in the menu xml files (for now).

The problem however is when I resize the screen everything remains squished
in the bottom left corner of the screen. The only ay I can think of solving
the problem so it looks 'normal' is to provide some kind of virtual scaling
system that the menu is designed against that is then translated in to
screen coordinates. For example I could use something simple like 100%
equalling the width of the screen, so a box might be 20% wide 15% high at
position 5%,5%.

How have you guys solved this problem? My solution presented seems like
it'll add a whole lot more math to the GUI to do all the translations for
the virtual screen space.

Thoughts?

Chris Brodie


NOTICE
This e-mail and any attachments are confidential and may contain copyright
material of Macquarie Bank or third parties. If you are not the intended
recipient of this email you should not read, print, re-transmit, store or
act in reliance on this e-mail or any attachments, and should destroy all
copies of them. Macquarie Bank does not guarantee the integrity of any
emails or any attached files. The views or opinions expressed are the
author's own and may not reflect the views or opinions of Macquarie Bank. 




-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

[GD-General] GUI Design

[Chris B. <Chr...@ma...>]

I've been building a GUI for my game but from day 1 have had a design issue I've been ignoring. From the beginning I've coded the coordinate system to OpenGL's bottom left origin. This is a minor pain as I'm the only one who needs to worry about the coordinates in the menu xml files (for now).

The problem however is when I resize the screen everything remains squished in the bottom left corner of the screen. The only ay I can think of solving the problem so it looks 'normal' is to provide some kind of virtual scaling system that the menu is designed against that is then translated in to screen coordinates. For example I could use something simple like 100% equalling the width of the screen, so a box might be 20% wide 15% high at position 5%,5%.

How have you guys solved this problem? My solution presented seems like it'll add a whole lot more math to the GUI to do all the translations for the virtual screen space.

Thoughts?

Chris Brodie


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. 

Re: [GD-General] mesh design issues

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

For the love, man, please, do NOT cross-post.  If necessary, post=
 
twice so dual independent threads can go instead of everything=
 going 
into cross-posting hell for everyone involved.

Brian

P.S. It definitely is not on topic for gd-design, which is about=
 game 
design issues, not programming issues

PPS GD-General would seem to be the most appropriate since this=
 isn't 
really DX related

[GD-General] mesh design issues

[Dan T. <da...@cs...>]

Hello all,

A couple friends and I are designing a rendering engine and we ran into =
a problem. The issue is this. When you are rendering meshes with =
different effects on them, how do you generalize the rendering? When we =
looked at it, it seemed like the best solution was a base class =
DrawableMesh, with various subclasses that do different things, such as =
a BumpMapMesh, a LightMappedMesh, etc. Each one of these subclasses =
would know how to set up the rendering for themselves based upon how =
many textures were allowed per pass on that card, and the various caps =
of the card. These meshes would have their verteces, textures, and =
shaders abstracted through a manager that handles reference counting for =
those objects, and that sort of thing.

The main issue we were having is the huge amount of subclasses required. =
I mean, to us it seemed you would wind up with a class for every =
permutation(combination?) of effect. e.g. you could conceivably(don't =
know *why*, per se) wind up with a =
LightMappedBumpMappedSpecularMappedSkinnedMesh, and that would have to =
reimplement the aspect of light mapping, bump mapping, specular mappng, =
and skinning. This seemed...wrong..to us. Does anyone have any better =
ideas?

This does seem a bit general for this list, so I'm ccing the GD-design =
and GD-general lists..please reply there if you feel it more =
appropriate.

Apologies for a duplicate if any...i sent it from the wrong accoutn at =
first and the list servers didn't like that.

Any help greatly appreciated.

Dan

RE: [GD-General] Level Editors

[Jamie F. <ja...@qu...>]

our engine (which is free for commercial use on PC) comes with an editor. it
has a robust plug-in architecture, although i'm not sure any third party has
yet used it in anger (but it's what all the supplied features use).

http://www.qubesoft.com/q/studio.php

we have a fair pedigree, as our core team was the core rendermorphics and
d3d team way back when.

j


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Ivan Galic
Sent: 18 January 2003 17:57
To: gam...@li...
Subject: [GD-General] Level Editors


Hi!

I know there was some discussion about level editors here, and someone
mentioned QERadiant. I have downloaded it, as well as all the plugins and
the source, but just to find out that it's not free for commercial use. I
thought it was GPL...
Does anyone know of a free 3d level editor(it doesn't need to be complex,
but should support basic stuff)? We're creating a small game(shareware
level) and  can't afford an expensive license for one of the proffessional
tools, and we'd like to avoid writing our own editor if possible. So, we're
looking for something free, preferably open source(GPL would be fine), or
very cheap.

Thanks.

------------------------------------------------
Live today so you don't have to do it tomorrow.
------------------------------------------------
-Ivan




-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
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] Level Editors

[gekido <mi...@ub...>]

there are editors that have been made that support the .map format that
aren't specifically tied to the genesis 3d engine - the genesis 3d license
doesn't say anything about using the editors for games that don't use the
g3d engine itself - only if you are using the rendering technology do you
need to worry about the logo & license requirements.

all of the editors are open source, not sure about the 'plugin
architecture' - the jet 3d editor is supposed to be more designed that way i
believe, that might be another option - www.jet3d.com

anyways, hope this helps.

mike w
www.uber-geek.ca


----- Original Message -----
From: "Ivan Galic" <dea...@ga...>
To: <gam...@li...>
Sent: Saturday, January 18, 2003 2:39 PM
Subject: Re: [GD-General] Level Editors


> > are you looking for .map support specifically?
>
> No. Anything would be fine. But I'd prefer something that includes source
so
> I can have my own format(or at least have a strong plugin architecture, so
I
> can write both exporters and custom entities for the editor).
>
> > most of the genesis 3d editors (and there are a half-dozen or more) can
> > export & import .map files if this is the format you are looking for
> > specifically, after which you could use your own bsp compiler to create
> the
> > bsp for your own engine format...
>
> That might be ok.
>
> > there are 3 editors provided with the realityfactory installation
package
> > (available from the main site http://rfactory.uber-geek.ca), all of
which
> > are free for commercial use - if you are only using the tools, then i
> can't
> > see there being any logo/licensing issues, you aren't initializing the
> > engine itself, so no need for the g3d logo, etc...
>
> Thanks for the link. Are you sure about those licenses?
>
> > there are several others available as well that aren't included with the
> rf
> > install - i'm sure a google search will find them for you
>
> Thanks.
>
>
> ------------------------------------------------
> Live today so you don't have to do it tomorrow.
> ------------------------------------------------
> -Ivan
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your
> clients even if they use browsers that are limited to 40 bit encryption.
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> 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] Level Editors

[Ivan G. <dea...@ga...>]

> are you looking for .map support specifically?

No. Anything would be fine. But I'd prefer something that includes source so
I can have my own format(or at least have a strong plugin architecture, so I
can write both exporters and custom entities for the editor).

> most of the genesis 3d editors (and there are a half-dozen or more) can
> export & import .map files if this is the format you are looking for
> specifically, after which you could use your own bsp compiler to create
the
> bsp for your own engine format...

That might be ok.

> there are 3 editors provided with the realityfactory installation package
> (available from the main site http://rfactory.uber-geek.ca), all of which
> are free for commercial use - if you are only using the tools, then i
can't
> see there being any logo/licensing issues, you aren't initializing the
> engine itself, so no need for the g3d logo, etc...

Thanks for the link. Are you sure about those licenses?

> there are several others available as well that aren't included with the
rf
> install - i'm sure a google search will find them for you

Thanks.


------------------------------------------------
Live today so you don't have to do it tomorrow.
------------------------------------------------
-Ivan

Re: [GD-General] Level Editors

[gekido <mi...@ub...>]

are you looking for .map support specifically?

if this is a requirement, then i might suggest you take a look at the
genesis 3d editors potentially.

most of the genesis 3d editors (and there are a half-dozen or more) can
export & import .map files if this is the format you are looking for
specifically, after which you could use your own bsp compiler to create the
bsp for your own engine format...

just an idea.

there are 3 editors provided with the realityfactory installation package
(available from the main site http://rfactory.uber-geek.ca), all of which
are free for commercial use - if you are only using the tools, then i can't
see there being any logo/licensing issues, you aren't initializing the
engine itself, so no need for the g3d logo, etc...

there are several others available as well that aren't included with the rf
install - i'm sure a google search will find them for you

mike w
www.uber-geek.ca

----- Original Message -----
From: "Ivan Galic" <dea...@ga...>
To: <gam...@li...>
Sent: Saturday, January 18, 2003 9:56 AM
Subject: [GD-General] Level Editors


> Hi!
>
> I know there was some discussion about level editors here, and someone
> mentioned QERadiant. I have downloaded it, as well as all the plugins and
> the source, but just to find out that it's not free for commercial use. I
> thought it was GPL...
> Does anyone know of a free 3d level editor(it doesn't need to be complex,
> but should support basic stuff)? We're creating a small game(shareware
> level) and  can't afford an expensive license for one of the proffessional
> tools, and we'd like to avoid writing our own editor if possible. So,
we're
> looking for something free, preferably open source(GPL would be fine), or
> very cheap.
>
> Thanks.
>
> ------------------------------------------------
> Live today so you don't have to do it tomorrow.
> ------------------------------------------------
> -Ivan
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your
> clients even if they use browsers that are limited to 40 bit encryption.
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> 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] Zen of Model Rendering

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

On Jan 18, 2003 at 08:07 +1100, Chris Brodie wrote:

> For a surface to be rendered you of course need a separate
> DrawArrays call (or something similar in D3D). I knew this so I used
> separate index lists. Now I render the triangles and it all works
> well, however performance bites and I have a thought. I have a
> single Vertex array. If I had an object of 10k polys using 10
> textures I now presented the vertex array to the API 10 times. This
> has got to be bad, since on average 90% of those verts won't even be
> needed. I guess I've found my performance problem.
> 
> So I decompose the giant vertex array in to mini vertex arrays per
> surface and remap the indices back in to the new array. This works,
> but I'm left feeling all those duplicate verts in each array (along
> seams for example) are evil.
> 
> Have I don't the right thing? Is this 'the' way to do it?

Yes, this is the normal way.  The duplicated edge verts are usually
much less evil than the alternatives.

-- 
Thatcher Ulrich
http://tulrich.com

[GD-General] Level Editors

[Ivan G. <dea...@ga...>]

Hi!

I know there was some discussion about level editors here, and someone
mentioned QERadiant. I have downloaded it, as well as all the plugins and
the source, but just to find out that it's not free for commercial use. I
thought it was GPL...
Does anyone know of a free 3d level editor(it doesn't need to be complex,
but should support basic stuff)? We're creating a small game(shareware
level) and  can't afford an expensive license for one of the proffessional
tools, and we'd like to avoid writing our own editor if possible. So, we're
looking for something free, preferably open source(GPL would be fine), or
very cheap.

Thanks.

------------------------------------------------
Live today so you don't have to do it tomorrow.
------------------------------------------------
-Ivan

[GD-General] Zen of Model Rendering

[Chris B. <Chr...@ma...>]

I've rendered and seen render models in may different ways. However I've always just fudges it and use a single texture per model. Now my engine is getting serious and I want multiple surfaces on my models. Easy, I hacked it in, but after a little while I realised something I had never noticed before(suprisingly).

For a surface to be rendered you of course need a separate DrawArrays call (or something similar in D3D). I knew this so I used separate index lists. Now I render the triangles and it all works well, however performance bites and I have a thought. I have a single Vertex array. If I had an object of 10k polys using 10 textures I now presented the vertex array to the API 10 times. This has got to be bad, since on average 90% of those verts won't even be needed. I guess I've found my performance problem.

So I decompose the giant vertex array in to mini vertex arrays per surface and remap the indices back in to the new array. This works, but I'm left feeling all those duplicate verts in each array (along seams for example) are evil.

Have I don't the right thing? Is this 'the' way to do it?

Many thanks

Chris


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. 

RE: [GD-General] IncrediBuild

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

We put time-hog slugs in the code that reduce your machine to a =
minimum-spec
one in normal builds. Solves that problem quite nicely. It's fairly
approximate, but then so is anything on a PC :-)

The gotcha is that the nature of the graphics code changes radically =
with
timing slugs, because the whole GPU/CPU parallelism thing is completely
different. But then graphics coders have their own huge nightmare with
different graphics cards and so on, so you can probably trust them not =
to go
bezerk with stuff if they have to make it run on a Voodoo1 or whatever.


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: Grills, Jeff [mailto:jg...@so...]
> Sent: 13 January 2003 17:06
> To: 'gam...@li...'
> Subject: RE: [GD-General] IncrediBuild
>=20
>=20
>=20
> To elaborate more, I find that programmers stop optimizing when code
> performs acceptably on their machine.  So, if their=20
> processors are 3 times
> as fast as the min spec machine, you've got problems waiting=20
> to bite you.
> Consoles solve that - you run the code on the console, which=20
> is the min-spec
> machine (and the max too).  I'm basically proposing applying=20
> that model to
> PC development, while still getting faster compile times.
>=20
> j
>=20
>=20
> -----Original Message-----
> From: Skelton, Jeff [mailto:jsk...@ea...]
> Sent: Monday, January 13, 2003 10:48 AM
> To: gam...@li...
> Subject: RE: [GD-General] IncrediBuild
>=20
>=20
> Make sure there is no possibility that your programmers will=20
> ever have to do
> console work in the future ;)
>=20
> Jeff
>=20
>=20
>=20
> -----Original Message-----
> From: Grills, Jeff [mailto:jg...@so...]=20
> Sent: Monday, January 13, 2003 8:37 AM
> To: 'gam...@li...'
> Subject: RE: [GD-General] IncrediBuild
>=20
>=20
>=20
> Too expensive?  That's insane.  The amount of programmer time=20
> it saves is
> immense -- it pays for itself very rapidly.  Besides, you=20
> don't need to
> upgrade programmer machines nearly so often, because compile=20
> times are much
> faster.  In fact, on the next project I lead, I'm going to=20
> push to leave all
> the programmers on the minimum spec CPU machine, and use=20
> Incredibuild to
> keep them working efficiently.
>=20
> j
>=20
> -----Original Message-----
> From: Emmanuel Astier [mailto:e_a...@ya...]
> Sent: Monday, January 13, 2003 10:20 AM
> To: gam...@li...
> Subject: RE: [GD-General] IncrediBuild
>=20
>=20
> I also used it for a project where compile times were
> important ( more than 30 minutes for a complete
> rebuild), and as we were quite a lot working on this
> title, we had to make a 'rebuild all' quite often...
>=20
> The gain was impressive ( around 4x / 5x faster ),
> it's really easy to use, the interface is really nice.
>=20
>=20
> We had some problems with some settings, but nothing
> really important...
> All the team wanted to buy it, but our manager said
> the cost was too high. Gosh...
>=20
> It was quite hard to get back to plain VC when the
> test period ended...
>=20
> Emmanuel
>=20
>  --- "Grills, Jeff" <jg...@so...> a =E9crit=A0: >
>=20
> > We use it, and we couldn't live without it - it cuts
> > our compile times in
> > half or more.  It only supports MSVC6, and right now
> > we won't upgrade to
> > MSVC7 until Incredbuild supports it properly.  It
> > also does a much better
> > job of finding necessary dependencies that MSVC6.
> > Sometimes a normal build
> > will fail to link, or have runtime problems, but
> > after doing an incredibuild
> > all those issues go away.
> >=20
> > It has some problems with custom build steps.  We
> > have some projects that
> > won't properly build with it (like any of our apps
> > that use QT).  But the
> > majority of our code works well with it.
> >=20
> > I think, if we had less programmers on the team and
> > could make sure they
> > were more diligent reducing compile time
> > dependencies, that it might not be
> > as beneficial.  But we're not in that situation, and
> > the package is crucial
> > to improving programmer workflow.
> >=20
> > Jeff Grills
> > Technical Director, Austin Studio
> > Star Wars Galaxies
> > Sony Online Entertainment
> > =20
> > -----Original Message-----
> > From: Gareth Lewin [mailto:GL...@cl...]
> > Sent: Monday, January 13, 2003 6:57 AM
> > To: Gamedevlists-General (E-mail)
> > Subject: [GD-General] IncrediBuild
> >=20
> >=20
> > I just saw IncrediBuild linked from flipcode, and
> > wanted to know if anyone
> > has used it ?
> >=20
> > (Hoping this isn't OT, but I know this list is
> > fairly open, and discussions
> > of speading up compile times is quite common even in
> > SWeng )
> >=20
> > _____________________
> > Regards, Gareth Lewin
> >=20
> >=20
> >
> -------------------------------------------------------
> > This SF.NET email is sponsored by: FREE  SSL Guide
> > from Thawte
> > are you planning your Web Server Security? Click
> > here to get a FREE
> > Thawte SSL guide and find the answers to all your
> > SSL security issues.
> >
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> > _______________________________________________
> > Gamedevlists-general mailing list=20
> > Gam...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> >
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557=20
>=20
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en=20
> fran=E7ais ! Yahoo!
> Mail : http://fr.mail.yahoo.com
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte are =
you
> planning your Web Server Security? Click here to get a FREE=20
> Thawte SSL guide
> and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Gamedevlists-general mailing list=20
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte are =
you
> planning your Web Server Security? Click here to get a FREE=20
> Thawte SSL guide
> and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Gamedevlists-general mailing list=20
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL=20
> security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL=20
> security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=20

[GD-General] New C# Wrapper for the OpenGL API

[Colin F. <cp...@ea...>]

2003 January 16th
Thursday

I have created a C# wrapper for the OpenGL API.

http://www.colinfahey.com/opengl/csharp.htm

I think this wrapper represents an improvement over
the few others that are available (for reasons I
discuss on the web page).

--- Colin

cp...@ea...
http://www.colinfahey.com

Re: [GD-General] Sharing DSP between static lib / DLL

[<cas...@ya...>]

Pierre Terdiman wrote:
> Now that I think about it, I might be confused a bit. Here's the thing :
>
> 1) In a standard DLL, if I want to export a function I write something
like
> :
>
> __declspec(dllexport)     int SomeFunction(int some_param);
>
> Then SomeFunction() can be found in the DLL, with a decorated name. Any
> application that wants to use it has to include the header, link with the
> .lib, and the .dll is used at runtime. You can't use GetProcAddress on
> SomeFunction(), unless you use a .def file.

You can't use GetProcAddress unless you know the C++ decorated name of the
function.


> 2) In a standard DLL, if I write this instead :
>
> extern "C" __declspec(dllexport)     int SomeFunction(int some_param);
>
> Then we have the same story, except you can now use GetProcAddress on
> SomeFunction() without a .def file, i.e. the name is not decorated. This
is
> handy in MAX file to get rid of the .def file, for example.

In C the names are not decorated, so you can use it as is.


> 3) Now, in a static library, I don't have any import / export marks. I
just
> have :
>
>     int SomeFunction(int some_param);
>
> If a DLL wraps that library, SomeFunction() doesn't appear in the DLL
(with
> a decorated name or not), so you can't use GetProcAddess() on it, but you
> can still use it in your app (the app beeing otherwise using the wrapping
> DLL).
>
>
> What are .def files useful for, exactly, when not using GetProcAddress() ?

The .def file and __declspec(dllexport) does exactly the same thing. On
mingw the compiler does not understand the __declspec(dllexport) directive,
so it depends on another tool that generates a .def file for it. The result
is the same. The problem is that gcc and vc++ decorate the function names in
a different way, so that tools is not as usefull as I thought.

What I think it could be going on, is that you are building the .lib file as
if it were a dll. The functions preserve the export/import tag in the lib
file. When you build the it as a DLL everything works as expected, and when
using a .lib file, the exported functions are added to the export and import
tables. I assume that the compiler is smart enough to notice that the
function does not need to be imported, like when you use an exported
function within the dll that exports it.

Well, I could be totally wrong, so just take your own conclusions. Hope that
helps.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es

RE: [GD-General] Sharing DSP between static lib / DLL

[Nicolas R. <nic...@fr...>]

Hi,

This is what we do here:
Let say that we have a "MyLib".

First the static library:

We have first a "MyLib.h" header which is:
including all headers of the library.
We have a "MyLibDefines.h" header which is included by all headers of
the library, and starts with:
#ifndef MYLIB_API
#define MYLIB_API
#endif
Then all public functions/classes are using MYLIB_API declaration.


The DLL project.

Only two files (usually in same directoy as MyLib)

MyLibDLL.cpp which is only doing:
#define MYLIB_API	__declspec(dllexport)
#include "MyLibDLL.h"

And MyLibDLL.h:
#ifndef MYLIB_API
#define MYLIB_API __declspec(dllimport)
#endif
#include "MyLib.h"


In outer project, when using the DLL, we just include "MyLibDLL.h".
When using the static lib, we include "MyLib.h"


Nicolas.




-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Pierre Terdiman
Sent: Monday, January 13, 2003 12:42 PM
To: gam...@li...
Subject: [GD-General] Sharing DSP between static lib / DLL


Hi,

I would like to have two versions of the same library :
- a static version (simple .lib)
- a dynamic version (a .dll)

This is easy enough by creating two projects (.dsp) and #defining
appropriate tokens.

But the original DLL project has a particular source-tree (in VC++),
that seems to be saved in its DSP file. Is there a way to somehow copy
that source tree to the other DSP (from the lib version), without
recreating everything in VC++ ? More important, how to easily keep both
in sync ? (the same problem arises with project settings, if I change
them in one version (say using RTTI or not), I'd like the other version
to use the same settings
automatically...)

I'm afraid it's not possible, but it's worth asking.

Pierre



-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte are you
planning your Web Server Security? Click here to get a FREE Thawte SSL
guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
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] Sharing DSP between static lib / DLL

[Pierre T. <p.t...@wa...>]

> Oh fine! I just thought that the export/import information was not
preserved
> in the lib file, and I had never tested that without a def file. It's nice
> to know that it just works.

Now that I think about it, I might be confused a bit. Here's the thing :

1) In a standard DLL, if I want to export a function I write something like
:

__declspec(dllexport)     int SomeFunction(int some_param);

Then SomeFunction() can be found in the DLL, with a decorated name. Any
application that wants to use it has to include the header, link with the
.lib, and the .dll is used at runtime. You can't use GetProcAddress on
SomeFunction(), unless you use a .def file.

2) In a standard DLL, if I write this instead :

extern "C" __declspec(dllexport)     int SomeFunction(int some_param);

Then we have the same story, except you can now use GetProcAddress on
SomeFunction() without a .def file, i.e. the name is not decorated. This is
handy in MAX file to get rid of the .def file, for example.

3) Now, in a static library, I don't have any import / export marks. I just
have :

    int SomeFunction(int some_param);

If a DLL wraps that library, SomeFunction() doesn't appear in the DLL (with
a decorated name or not), so you can't use GetProcAddess() on it, but you
can still use it in your app (the app beeing otherwise using the wrapping
DLL).


What are .def files useful for, exactly, when not using GetProcAddress() ?

Pierre

Re: [GD-General] Sharing DSP between static lib / DLL

[<cas...@ya...>]

Pierre Terdiman wrote:
> I just tried with a single function and it seems to work without def
files.
>
> So I think I'll do that..... :)

Oh fine! I just thought that the export/import information was not preserved
in the lib file, and I had never tested that without a def file. It's nice
to know that it just works.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es

Re: [GD-General] Sharing DSP between static lib / DLL

[Pierre T. <p.t...@wa...>]

> This is what I sometimes do:
> - Create the .lib in one project.
> - Create an empty dll project, that includes the library and defines some
> exports.
>
> However, I don't know if that would be possible if you are not using a
.def
> file. The cygwin tools and mingw also, come with a handy tool (dllwrap)
that
> automatically creates complex .def files for a project (parsing the
declspec
> commands), maybe you could use it as a custom build step. If you are
> interested in this approach I could elaborate more.

I just tried with a single function and it seems to work without def files.

So I think I'll do that..... :)

Thanks,
Pierre