Darkplaces with Quoth

[LordHavoc]

The screenshots are attached. Thanks for your time.

Were you moving quickly when taking those shots? the fps and Total in the r_speeds 2 report are very different, for example the Total in the second one shows over 1.17 seconds spent per frame, but shows 46 fps, something weird there.

Could you re-test this in the current beta version of the engine? I see that you're using the stable version (from the layout of the r_speeds display).

[yhe1]

I used your Jul 5 beta. The beta had problems loading e1m2quoth, I could load it via the console, but it would crash if I exited level one.

Screenshots are attached again. I had "always run" on took the screenshots when I moved in the the low FPS spot.

I can't attached the screenshots here because they are too big, I have sent them to your email. Thank you.

[Spirit]

As I said above I am very sure it is not Quoth related at all.
Please try if you get the same behaviour in the original http://www.quaddicted.com/filebase/e1m1rmx.zip (play in normal Quake).
If so, you will probably get it also if you play the map with "deathmatch 1". Just to close down on the problem.

For me the fps stuttering is most notably when turning. Also the fps are wildly fluctuating even when standing still.

PS: I noticed that r_speeds 1/2 eats a considerable chunk of my fps, 2 a bit more than 1. On e1m1rmx thats from ~100 to ~70 (in the "fast" places). Maybe it's normal, just thought I'd mention it. Maybe it is related to the same problem of some graphics card suckyness.

[Spirit]

I tried capturing that behaviour in a video, of course that is hard to do but I think I succeeded a bit.

http://www.quaddicted.com/stuff/e1m1rmx.avi (4MB, H264 codec, no sound)
as comparison you can see http://www.quaddicted.com/stuff/e1m1.avi (7MB, H264 codec, no sound)

Even though the framerate went a bit deeper from the capturing (I used an external tool) the e1m1rmx vid shows nicely a) the fps going down and b) the visual and mouse lag even if the fps are "high" (50-70).

[LordHavoc]

As I said above I am very sure it is not Quoth related at all.
Please try if you get the same behaviour in the original http://www.quaddicted.com/filebase/e1m1rmx.zip (play in normal Quake).
If so, you will probably get it also if you play the map with "deathmatch 1". Just to close down on the problem.

For me the fps stuttering is most notably when turning. Also the fps are wildly fluctuating even when standing still.

Wildly fluctuating fps report is something I need to fix - I haven't figured out why it does that but I'm sure I just did the fps analyzer wrong somehow.

PS: I noticed that r_speeds 1/2 eats a considerable chunk of my fps, 2 a bit more than 1. On e1m1rmx thats from ~100 to ~70 (in the "fast" places). Maybe it's normal, just thought I'd mention it. Maybe it is related to the same problem of some graphics card suckyness.

r_speeds 1 shows text, which slows it down, just like the console does, or scoreboard, etc.

I don't know why text slows the game down so much though.

As for 2, that slows it down because it calls glFinish() between each stage of rendering, to get accurate timing (how long it takes to actually draw the pixels), mode 3 gives timings without that synchronization of CPU and GPU (tends to jump around more).

[LordHavoc]

I used your Jul 5 beta. The beta had problems loading e1m2quoth, I could load it via the console, but it would crash if I exited level one.

Screenshots are attached again. I had "always run" on took the screenshots when I moved in the the low FPS spot.

I can't attached the screenshots here because they are too big, I have sent them to your email. Thank you.

The screenshots seem to show a major fps drop in that location, along with a major jump in flickering lightmaps - perhaps these are responsible? It's a serious driver flaw if it dislikes my lightmap uploads, but maybe it's just some case Intel didn't optimize...

You can try r_dynamic 0 to see if it helps.

[LordHavoc]

I tried capturing that behaviour in a video, of course that is hard to do but I think I succeeded a bit.

http://www.quaddicted.com/stuff/e1m1rmx.avi (4MB, H264 codec, no sound)
as comparison you can see http://www.quaddicted.com/stuff/e1m1.avi (7MB, H264 codec, no sound)

What engines were used for those videos? Are they both DP? The framerate is massively different between them, and very erratic.

I can't really learn anything from the framerates as they're updated only a few times a second and you're turning too fast for them to stabilize.

Nor can I see r_speeds (which updates on a frame by frame basis, so I would be able to analyze it a bit).

Even though the framerate went a bit deeper from the capturing (I used an external tool) the e1m1rmx vid shows nicely a) the fps going down and b) the visual and mouse lag even if the fps are "high" (50-70).

Not using the built in cl_capturevideo cvar? It has a cl_capturevideo_realtime 1 option to record in realtime (normally it tries to make the game run at 30fps - even if it runs slow in the process, and has to render sound differently to do so). Each time it's turned on it starts a new avi file, using the Intel 4:2:0 codec (uncompressed).

Edit: I don't know how I would be able to "see" input lag in a video.

[yhe1]

I tried r_dynamic 0 and the problem is still there.

[Spirit]

Yes, both are DP. Same settings, same everything, just different maps.
The cl_capturevideo looked like a rather wrong idea to me as I am tried to capture the fps. Rendering at 30fps alters that. But if it might help, here is another vid captured that way. "Ingame" the framerate drops in the middle of the turn (when looking at the edge/when the other open space comes into view at the screen side).
When I use "r_showportals 1" the fps are much higher, the fps drop still occurs though. "gl_lightmaps 1" has not much effect. "r_dynamic 0" none.

The whole performance on such maps (masque or marcher would be two more examples) is very bad. I think the problem might be somewhere else and not related to a specific place on a map. I mean it is normal to have less fps looking into open space then at a wall. This map just has such low fps that the drop here goes to a noticable low range.

I played a bit with "r_showtris 1" and "r_disabledepthtest 1" and it seems that the drops come in the moment when a rather big/detailed new segment of the map gets rendered.