Bad fps in latest git?

I pulled yesterday, has anyone noticed any odd fps reductions? I normally get 60-85 but I've been getting 30 into the low 10s...

Oh yea, it's definitely sluggish. Been slow for a while... but it's becoming unplayable now.

FPS has ALWAYS been an issue for me with the git builds, I've never had that problem with the preview release though. I also can't get any sound in the git version either for some reason, I think it's because the git only has SDL and not GLX (for some reason GLX has always worked best for me, even in Nexuiz, SDL either has bad or non-existent sound for me since 2.5 as well) which is what I always run.

Okay, but no one notices it like an very recent thing then...ok.

I have a 1 GB 256 bit GTS 250, not the best of the best but still decent, I'd think :< I'd hate to turn off all the graphics stuffs.

I think it's because the git only has SDL and not GLX

git has GLX; just start the game with ./all run glx instead of ./all run.

xonotic has always ran slower on my computer then I would expect, considering how powerful my computer is.

I think it's because the git only has SDL and not GLX

git has GLX; just start the game with ./all run glx instead of ./all run.

Oh lol didn't know that.

I downloaded the git yesterday (it took days to find out how it works). I played race, but had about 250-400 fps. Not that bad

I downloaded the git yesterday (it took days to find out how it works). I played race, but had about 250-400 fps. Not that bad

Screw you

The problem I am seeing is that I get great fps when there are no players, but if I put a few bots in, as soon as they get on the screen, the fps drop *dramatically*. Now that is to be expected to a degree, because rendering players is always taxing, no matter what game or engine it is. However, the drop is borderline ridiculous, talking from 200-250 down to 30-50. I tried on 2 different systems, and 2 different OS's.

Now I've looked at the code, and don't see a reason for this drop, however I will say that those player models are might be a bit poly heavy for a deathmatch game. I read somewhere that they were 2500-4000? Correct me if I am wrong on that. If they are that high, that is too high for that amount of detail. With DP's ability to use normalmaps, most of that detail should be in the texture and not the mesh.

If I am wrong about that polycount, and say it's in the 1500-2000 range, then there is likely an issue with DP. I think DP supports far too many formats and should trim the fat, IMO, that would be a start.

I'm also not convinced that DP's fps counter is even accurate either. 40 fps feels like a slideshow compared to 40 fps on other games.

The problem I am seeing is that I get great fps when there are no players, but if I put a few bots in, as soon as they get on the screen, the fps drop *dramatically*. Now that is to be expected to a degree, because rendering players is always taxing, no matter what game or engine it is. However, the drop is borderline ridiculous, talking from 200-250 down to 30-50. I tried on 2 different systems, and 2 different OS's.

Now I've looked at the code, and don't see a reason for this drop, however I will say that those player models are might be a bit poly heavy for a deathmatch game. I read somewhere that they were 2500-4000? Correct me if I am wrong on that. If they are that high, that is too high for that amount of detail. With DP's ability to use normalmaps, most of that detail should be in the texture and not the mesh.

If I am wrong about that polycount, and say it's in the 1500-2000 range, then there is likely an issue with DP. I think DP supports far too many formats and should trim the fat, IMO, that would be a start.

I'm also not convinced that DP's fps counter is even accurate either. 40 fps feels like a slideshow compared to 40 fps on other games.

Most of the performance hit in respect to models comes with the extra shaders and lighting. Relief Mapping, High Dynamic Range Bloom and Realtime * Lighting hit model rendering hard. 2500-4000 doesn't seem very high IMO...

Most of the performance hit in respect to models comes with the extra shaders and lighting. Relief Mapping, High Dynamic Range Bloom and Realtime * Lighting hit model rendering hard. 2500-4000 doesn't seem very high IMO...

HDR and bloom are post process effects and really shouldn't be a big hit. I notice very little fps difference when they are turned on in fact.

Relief mapping shouldn't be too bad of a hit either, not on a modern GPU, and that isn't done on player models is it? (I'm thinking it isn't but don't want to say for sure).

For performance considerations please make sure you have a release build, not a debug one (standard for GIT builds). The performance difference is significant IIRC.

Also for bots it's difficult to properly distinguish between the usual bot-slowness (the bots used to eat a lot of CPU, this may still be so) and the eventual rendering slowness. I recommend recording a bot-match demo and then doing a timedemo, this would keep the bot CPU-hogging out of the equation.

@Irritant: Congratulations on the latest Alien Arena release, btw!

Relief mapping, HDR, anti-aliasing, and anisotropy are things that will mess my frame rate up, though anisotropy to me isn't so noticeable past 4 most of the time due to the game's speed. HDR and relief mapping add a bit visually, but I usually just settle for off-set mapping and bloom instead, this was the case on my last monitor (which was at 1280 X 1024 res) and on my current monitor (which is 2048 X 1536) with a 256 bit Geforce 9800GTX handling video. Anti-aliasing is pretty much useless when running at my monitor's native res, as it's not noticeable at all.

Well, if your computer is too slow for the normal xonotic, just download Xonotic 0.1akari. And your computer will be able to run it, with a good fps, even with graphics on ultra.

But well, don't expect a lot of eyecandy

Most of the performance hit in respect to models comes with the extra shaders and lighting. Relief Mapping, High Dynamic Range Bloom and Realtime * Lighting hit model rendering hard. 2500-4000 doesn't seem very high IMO...

HDR and bloom are post process effects and really shouldn't be a big hit. I notice very little fps difference when they are turned on in fact.

Relief mapping shouldn't be too bad of a hit either, not on a modern GPU, and that isn't done on player models is it? (I'm thinking it isn't but don't want to say for sure).

Bloom is not a hitting effect, but HDR is. Where bloom simply uses a mipmapped downscaling of the scene, HDR uses some form of a true blur. As for relief mapping, I can inform you that the gpu makes 15 passes in sampling for a single pixel. There are 10 linear steps which are slow enough, even on my GTX465, then there are 5 binary search steps in the height map, then that information has shadowing and lighting applied. Relief mapping is, and always will be a SERIOUS performance hit(quality will increase with future generations). It is even more serious when lighting is handled in realtime. As prebaked lightmaps do not suffice for an easy render. I don't know how that affects models, but some portions of models do use Normals+Height. A poly count of 4000 vs optimizing and improving shaders is an easy win for the shader work.

I remember from the past that on my machine gl_vbo 0/1 or r_glsl 0/1 caused huge FPS drops on my ATI cards in the past when rendering enemy models. Just try

Don't host a local server with bots - FPS instantly drops in half. The bot code we have is so old and slow, it basically needs re-written from scratch.

Also: Git checkouts are significantly slower than real builds.

I pulled yesterday, has anyone noticed any odd fps reductions? I normally get 60-85 but I've been getting 30 into the low 10s...

I know it's very late, but...

some possibly slowing down changes in the week before the post:

• GLSL 1.30 support - try adding the command line argument -noglsl130 (as in ./all run -noglsl130) for a test to turn this off
  
• Some more cvars for offsetmapping; these MAY make the shader slower. Try turning off offsetmapping and reliefmapping (these changes don't do anything of these features are off)
  

<flame>
It looks like in the not so distant future Xonotic may perfectly justify the existence of 580's.
</flame>

Yeah, local with bots is a tard.

Besides: Bots that you have to set waypoints for MANUALLY? Q3A at least had AAS maps, and Witcher 2 uses a freaking Path Engine for AI and it's not slowing anything down, and Path's gimmick is real-time path finding, even with consideration of dynamic obstacles. Now I know that this would be hard, but consider:
Bots should have personalities. I think this has been brought up some time ago, but I'm gonna repeat it. It could be weapon preference, fight tactics (melee vs. combos vs. stupid charging vs. camping), maybe even randomized chat messages off a list (a la Quake 3 again).
Bots should not wander around aimlessly, but try to assume places to occupy, in consideration with other players/bots in sight, or at least vis sector. If faced with a choice of two opponents in the same cluster, they should be able to judge which one to take on.
Team bots should have a basic understanding of roles and commands, listening in to chat channels, and spotting orders (like "guys defend" → at least one bot should defend the base).
And last but not least, BOTS SHOULD NOT REQUIRE EFFIN WAY POINTS! This is not a method of creating good AI for fights, this is making a rail shooter out of them. They're too predictable, and should not be IN ANY WAY turrets moving along a pre-set path until a player is in range.

I think I'm gonna post a topic about it on suggestions.