Subject: [Nel] Getting NeL up and running.

From: Leighton Haynes <[email-masked]>
Date: Sun, 25 Feb 2001 01:29:01 +0800

Hi Guys,
    Well, i finally managed to get the sample snowballs client and
    server up and running, though it required quite a few code hacks
    on my part. (Damn my wacky machine config). Oh yeah, this is all
    for the linux code as well.. my machine is basically debian woody
    (though various gnome/wine/sawfish things are latest releases
    compiled from source)

    Most of my 'fixes' aren't really, they address the symptoms rather
    than the cause, though I don't think I've broken anything major 
    with them ;) If anyone wants to give me some hints on what could
    be causing them, please do. 
    In case anyone else has similar problems, things I got were:
        time_service was exiting: temporarily fixed by removing the
          call of _Callback() in checkConfigFiles() method of 
          code/nel/src/misc/config_file/config_file.cpp. I haven't
          managed to work out where it's being set, or why the value
          isn't correct yet.
          I gather the point of the Callback function is so that the 
          client which has loaded the Config file can become aware 
          of any changes to the parameters in the file, the time_service
          doesn't appear to set any callbacks for this though. *shrug*
        moves_service - suspect it had the same problem as above, it
          _was_ segfaulting, but went away after the above hack.
        the client was exiting with a message in the logfile about 
          being unable to load file "data/". Managed to eventually track
          it down to some of the texture loading code in 
          code/nel/src/3d/landscape.cpp. The loading of the diffuse
          texturemap doesn't do a check for textName == "" though
          the loading of the alpha texture map does. Haven't worked 
          out yet why it's decided that the textName is "" (it's too
          late ;)). I modified the code to do a test for textName == ""
          and made it default to loading the CTextureCross texture.

    As some other comments - processes are defaulting under linux to
    some (IMHO) really ugly behaviour of 'fork'ing another process,
    the sole purpose of this appears to be to let them run in the 
    background. I don't see any really good reason for doing this,
    since it can be quite easily achieved by 'nohup'ing it and 
    shoving an '&' on the end of the line. Am I missing something?
    (It makes it a bugger to debug, I can't run 'strace' on them effectively
    etc etc. Obviously, i just commented the code out of my version ;)
    Perhaps a commandline switch would be more appropriate?)

    Oh well, after all that, the client runs at about 5fps ;) Guess
    I should spend some time seeing if I can get it faster eh?
    Can anyone give me some benchmarkish figures for framerate 
    under window~1? For a P3-550 with Geforce(1) would be best ;)
    Then I can have a base to work from.

    Anyhow, nice work guys. The framework (which I've forcibly had
    to poke) seems pretty decent (I'm reserving judgement for further
    praise until I've had more experience with it ;)). Having spent
    some time working on one of these, I know just how much work it
    is to get anything this complex working. 

Leighton...

--

Part-time student. Full-time Programmer. 
Seeking the 36 hour day and the 10 hour working week.
(08) 9272 9058 (Home - like I'm ever there)
0401 335 136 (Mobile - like it's ever on)

---

From: "Bret Guillet" <[email-masked]>
Date: Mon, 26 Feb 2001 09:42:42 -0600

I'm running windows with one of the geforce cards and an Athlon 500
and
get roughly between 12 and 14 fps. And that seems to be inline with
others who have similar capabilities.

---

From: Vincent Archer <[email-masked]>
Date: Mon, 26 Feb 2001 18:22:56 +0100

> others who have similar capabilities.

It is heavily dependent on what settings you use for the calculation
of patches into polygons, since this (in the current generation of cards
anyway), is done chiefly in software.

-- 
Vincent Archer                                         Email: [email-masked]

Nevrax France.                              Off on the yellow brick road we go!

---

From: "Michael Warnock" <[email-masked]>
Date: Mon, 26 Feb 2001 12:59:11 -0800

> others who have similar capabilities.
I'm running an athlon 700 with a geforce2 gts and get 15-30 fps (depending
on scene complexity) with cvs from a couple days ago (and some modifications
we're making which should only make it slower)  The speed hardly even goes
down when I crank the resolution up to 1280x1024 which indicates to me that
we are currently cpu limited.  You might also try commenting nlinfo() lines
out if u really want a few more fps, but just judging by the speed
improvements since snowballs .1 I'm not worried about future performance:)

michael warnock
in-orbit entertainment inc.

---

From: Leighton Haynes <[email-masked]>
Date: Tue, 27 Feb 2001 10:18:00 +0800

> anyway), is done chiefly in software.
How does one change these settings?

Also, i read somewhere that you're going to use ROAM? I take it this isn't
implemented yet.

One thing that would be nice for those of us not in Nevrax would
be a roadmap showing featureset planned and whos working on them 
(and when). This would allow people out here to grab a feature they
felt like implementing, and have a go at it, without running into 
situations where someone else has already done it.

Leighton...

--

---

From: "Vianney Lecroart" <[email-masked]>
Date: Tue, 27 Feb 2001 10:08:24 +0100

I already sent a mail in this list about how to increase the fps in
snowball.
(vincent archer, you should put this in the FAQ ;-)

---------------------

Yes, snowballs is slow because it s a prototype for a futur game.
There s no optimisation and our game is planning to work with next computer
generation.

Anyway, you can increase the frame rate with changing the default value of
the tesselation of the landscape and others variables.
In the client.cfg, you have 2 variables:

LandscapeTileNear = 50.000000;
LandscapeThreshold = 0.001000;

The first one is the distance, in meter, of the near algorithm, if you
decrease the
value (putting 10 for example) should increase the framerate.
The second variable is the threshold of the tesselation of the landscape,
you can
increase the value to increase the frame rate (try 0.01 or 0.1 for example).
of course,
if you do that, there will be less details on the landscape.
You can modify these 2 variables in realtime using chat commands. You just
have to
write:
/setthre 0.1
to set the LandscapeThreshold to 0.1
/settilenear 10
to set the LandscapeTileNear to 10
when you change variables in realtime in the game, they are automaticaly
store in the
client.cfg so you don t have to do it again on next launch.

With this, you can increase the framerate from 10 to 30 fps on a fast
computer.

On our computer, the frame rate is around 10-15fps with default value and we
have:
Athlon 750Mhz, 256Mb RAM, GeForce256 32Mb RAM.

Another thing you have to know is that we use lot of processor time.
If we change only the processor and put an Athlan 1Ghz, the framerate
increase
to 20fps. But if you put a GeForce2GTS, you ll see no difference in the
frame rate.

The fill rate of the 3d card isn't use a lot, you can try to put the
resolution
to 320*240 or 1600*1200 and you ll see that the framerate doesn t change a
lot.

Anyway, we know that snowballs is slow :-/

Vianney Lecroart
---
lead network programmer / nevrax.com
icq#: 6870415
homepage: http://ace.planet-d.net
www.geekcode.com: GCS/E d- s+++: a-- C+++$ UL++ P- L+++>+$ E+>- W++ N+ o? K-
w++$ O- M- V- PS- PE? Y PGP t 5? X+ R- tv++ b- DI D+ G e++ h+ r-- y?

---

From: Vincent Archer <[email-masked]>
Date: Tue, 27 Feb 2001 18:00:05 +0100

>     be causing them, please do. 

Well, we don't have hints, because, as you may surmise, these do not
occur here.

>           doesn't appear to set any callbacks for this though. *shrug*

That's exactly what it's supposed to be, yes. So, either the callbacks
are set incorrectly, or they are called while they should not be.

>           and made it default to loading the CTextureCross texture.

That's the strange part. It should not be loading an empty file name
at all. I suppose the check doesn't hurt either, so we'll look at
integrating it in future commits.

>     background. I don't see any really good reason for doing this,

Well, there is one. Basically, if you look at these processes, you'll
see they first do a set of initialisations, then fork. The whole
fork-and-exit sequence is used to guarantee that service N+1 isn't
started before service N has at least performed the minimum required
initialisations.

>     shoving an '&' on the end of the line. Am I missing something?

You could too, but you'd have to slide in a "reasonable" sleep N in
the shell startup script. With reasonable varying a lot.

>     Perhaps a commandline switch would be more appropriate?)

That'll be added, yes.

---

From: "Lionel Berenguier" <[email-masked]>
Date: Wed, 28 Feb 2001 09:34:41 +0100

----- Original Message -----
From: Leighton Haynes <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 27, 2001 3:18 AM
Subject: Re: [Nel] Getting NeL up and running.

> Also, i read somewhere that you're going to use ROAM? I take it this isn't

We use a ROAM-like algorithm. See class CLandscape for more details. It is
based on bezier patchs, not on heightmap, so it is slighty different from
ROAM (as example, you can't deduce tesselation neighborhood from topology (a
patch graph is not as simple as a heightmap :) )). There is lot of features
(from Tiles, to distance based geomoprh) which make it different from the
original ROAM document.

Actually, I tink the only thing copied from ROAM is the triangle split/merge
scheme.

Lionel.