[Freeciv-Dev] Re: [Re: Performance (was: [Re: [OpenGL client (was Re: Re: Project)] (fwd)])]

[Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx>]

On 3 Feb 2000, * wrote:

> Jules Bean <jmlb2@xxxxxxxxxxxxxxxx> wrote:
> > On 2 Feb 2000, * wrote:
> > 
> > > I mentioned in the previous mail about performance issues.  The main
> issues
>>> are:

>>> 2) The big issue, the number of polygons.  Its obvious that we'll want more
>>> than one polygon per terrain square, as a general rule  ;)  In fact, for a
>>> realistic mountain square, for example, you'd probably want at least 5x5 (25
>>> squares, 50 triangles).  On a reasonable map of, say, 600 squares with only

Even better would be to use bump mapping... i doubt the performance would
be great tough :-)

> Silly me did the math wrong  I was interpreting megs for k  ;)  Its not near
> as bad as previously thought, but I will still want to do disk caching.  Also,
> any ideas on optimizing a 3d landscape?  Obviously, removing polygons that are
> too far away, off the screen, etc for openGL will help.  Also, is there a way
> to define a 3d model, and then just call the model, instead of making
> GL_TRIANGLES each time it draws?  I'm gonna mess around, but suggestions are
> always very helpful/time saving.

I guess what you want is to use display lists.  Also: there are other
methods (not GL_TRIANGLES) do define polygon meshes.  Remember several of
the vertexes are shared between squares so you could save some ram there.

I highly advise you to read the OpenGL Programming Guide (aka Red Book) 
before looking into this.  It is the "bible" of OpenGL programming and is
quite an easy read.  Get the one for OpenGL 1.1 (an 1.2 version of book
is on the works apparently).

> Perhaps most of my performance issues are due to the fact that I have a 2 year
> old laptop, and it undoubtably has no 3d acceleration.  Regardless, even
> without 3d acceleration its fast enough to generate single frames for people
> without too much wait.  I just think it may be a problem when, say, someone is
> trying to move a unit quickly and it has to do a frame for each movement
> (remember, I can't just redraw a part of the screen, at least, don't know how
> to).

You can do some tricks in double buffer mode to redraw parts of the
screen.  (again this is in the Red Book).

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa