Hello,

first of all, this is not an accusation of any developer(s), nor a command to FIX IT NOW!!!11 This is just an obversation from my side regarding the FPS-performance of Nexuiz SVN compared to Nexuiz v2.4.2

As a rule of thumb I can now say that my FPS counter shows 2-3x more in Nexuiz v2.4.2 than in Nexuiz SVN. The parts of my config.cfg dealing with FPS-related settings are equal in both installations.

- Are there known reasons for this?

Note that this is not entirely map-specific (at least not to my little knowledge, I copied some bsp files from SVN over to 2.4.2 and the performance in v2.4.2 was still much better) and also not entirely engine specific (when I copied my SVN binary into my v2.4.2 directory, the performance of the 2.4.2 binary and svn binary was similar)

Is it CSQC's fault maybe?

- Are there any new variables that could tweak performance a little?

- Who else (other players) can confirm what I'm saying?

Btw, my hardware is Windows XP x64, GF 8800 GTS. Now, in SVN, the FPS counter still shows values that seem to be big enough for playing, and I also can not say that I get a lot of weird stuttering or anything like that, I've just been wondering...

Two things that enter my mind:

- more clever deluxemapping that doesn't decrease brightness on average, but is more expensive

- higher resolution (external) lightmaps (of course won't affect maps copied from 2.4.2)

I ran timedemos from demo1.dem on my current system (E6750, 4GB RAM, ATi HD4670, XP Pro 32) and had following results:

Nexuiz 2.42:

1910 frames 42.5180000 seconds 44.9221506 fps, one-second fps min/avg/max: 24 48 94

Nexuiz SVN (enginedate 22:09:31 Jan 23 2009 8667 debug):

1910 frames 57.8890000 seconds 32.9941785 fps, one-second fps min/avg/max: 16 37 98


Unfortunately I can't run a bench on the current SVN, as my builder is quitting with an error again. So the difference is obvious, at least at high settings.

I'm wondering if somebody here could fix me a config.cfg with the most hardware-raping settings possible and give it to me. I don't think I'm familiar enough with the variables to do that by myself.

- The external lightmaps is reducing my fps also
- And there might be new content that reduces fps. Some models is replaced, some with higher polygon count.
- CSQC means more stuff done on the client, so thats using cpu.

SavageX wrote:Two things that enter my mind:

- more clever deluxemapping that doesn't decrease brightness on average, but is more expensive

- higher resolution (external) lightmaps (of course won't affect maps copied from 2.4.2)

Well, first of all, I'm talking about FPS losses while using my lowest details config, which means that I have settings like deluxemapping disabled - in this case, the first point should not have any effect

About the second point: What do I exactly have to do get the detailed-light-maps-feature to work (that is, in an v2.4.2 environment using a SVN engine), so that I can do an exact comparison?

Disable the external lightmaps from settings and try again?

GreEn`mArine wrote:About the second point: What do I exactly have to do get the detailed-light-maps-feature to work (that is, in an v2.4.2 environment using a SVN engine), so that I can do an exact comparison?

You need a recent engine, the updated BSP files and the subdirs containing the lightmaps.


Anyway, if you're on really low settings: The higher the framerate the more often CSQC has to draw stuff. What framerates are we talking about?


edit: Something you may want to try on SVN that is not possible in 2.4.2: Disable "Use Lightmaps" in the effects settings. Can double the FPS on my rig on e.g. Strength.

SavageX wrote:edit: Something you may want to try on SVN that is not possible in 2.4.2: Disable "Use Lightmaps" in the effects settings. Can double the FPS on my rig on e.g. Strength.

HOLY CRAP!!!
Doubles my FPS as well and basically gives me my 2.4.2 framerate back. My problem was that I was getting "only" about 250 where I used to have 600 or so (capped to 500). Now they are back to 500 and more, yay.

/me hugs SavageX *happy*

There is, however, another thing I noticed that seems "odd" to me. When standing still I can see my FPS dropping by a few 100 FPS, but once I move the mouse or walk around, the FPS go up again. Is this a feature? It's basically very smart as you really don't need more than 100 FPS when standing still, but only during movement.

You don't need 500 fps either. At max to your screen refresh rate with vsync disabled. This way you can enable lightmaps again.

hehe. No, I won't let myself get trolled by you. Nice try though

I'm telling the truth. If you would like to read I even could write why, but as you wish...

yeah but there will be VERY visible stripes on my screen (it's not that I wouldn't have tried your suggestion before already). With cl_maxfps 500 the stripes are still there, but are much smaller and do not appear as that disturbing to me anymore.

So you say you get stripes when vsync is enabled? That is exactly what vsync means to remove. Must be a graphics driver problem then. vsync works fine and stripeless for me.

Vsync creates lag between your actions and when they are shown on the screen.

You can get stripes if there is desync between max_fps and screen refresh rate.

divVerent wrote:So you say you get stripes when vsync is enabled? That is exactly what vsync means to remove. Must be a graphics driver problem then. vsync works fine and stripeless for me.

No, I am not using vsync due to the lag it introduces.
When NOT using vsync and setting cl_maxfps to 60 (which is equal to my screen refresh rate) I do get stripes, however.

That's absolutely normal.

If dp framebuffer filling and rendering it on the screen desyncs, then yes. Dunno if it is possible to control synchronization without using vsync (probably no). You will still get stripes on 60 screen even when running with 500 fps or more, cause LCD screen can change from grey-to-grey/black-to-white only - use graphics card framebuffer - 60 times per second.

I play without vsync and cl_maxfps set to 63, slightly above my monitor's refresh rate. That way the tearing will drift "randomly" across the screen, which is much nicer than a slowly drifting tear. Vsync just doesn't work AFAIK with the ATI fglrx driver.

There shouldn't be tears if dp always rendered framebuffer bytes ahead before this block of bytes would be sent to the monitor and monitor refresh rate would be equal to rendering rate of dp to keep constant distance.

Yes, but 60 Hz isn't exactly 60 Hz (or 72, or whatever). Depending on temperature and monitor parameters, these vary a little.

vsync is the only way to get this synced.