Beta 3 can no longer play the Warp demos. Thx 

Beta 3 can no longer play the Warp demos. Thx

I thought I wrote about this a while back but I obviously didn't. I've removed support for the protocols used by these demos; it was getting silly having 7 different protocols in the engine, so they went. Playing the Warpspasm demos is honestly not high on the priority list.

Ask me nicely enough and I might add support back in on the client-side only, and for the purposes of demo playback only. 

There now seems to be no fog in Quoth maps, I've tested APSP2 and Ruined Nation. 

It seems that only nehahra fog works now, I've also tested elements, and there was no fog there either.

1.866b worked fine. 

Well I did say that compatibility between Nehahra fog and regular fog was a difficulty. I'll check it out, but if it's not resolvable then Nehahra fog is going to go. 

In 1.8.7 rc1, the fog in elements works now, but still no fog in Ruined Nations. 

APSP2 also has fog now. 

In 1.8.7 rc1, the fog in elements works now, but still no fog in Ruined Nations.

There actually is, but Ruined Nation sends it's fog colours on a 0-255 scale whereas everything else sends them on a 0-1 scale. So fog colour is coming through as fully white, and you might not be noticing it properly. 

It also uses a VERY low density value - 0.02 - whereas the norm for most maps is in the 0.05 to 0.1 range. 

Hi mh, I noticed that since 1.8.7, directq some times have slight stuttering at certain parts of maps. (It only happen when you enter an area for the first time) It is kind of hard to replicate, because sometimes it happens, and sometimes it does not. For example, it happened with e1m1rmx by czg and vondur. I didn't notice anything like this in 1.866b. I haven't been able to pin down a pattern of where or when it does this, but maybe you can test the performance of 1.866b vs. 1.8.7? 

Normally, the FPS is 71, but these stuttering cause it to go down to 30-40. 

Entering an area for the first time? Sounds like textures or lightmaps that haven't been seen before are being downloaded to your video RAM. Odd, and interesting. 

OK, I'm going to put on my psychic hat here and guess that you're using a texture pack. Most likely Rygel's but possibly QRP. (This would have been useful info in your original post, by the way.)

If I'm right then the cause of this is that certain textures are being seen for the first time and as a result need to be pulled into video memory (my psychic hat tells me that you also have either Vista or 7 - also would have been useful info). The sheer size of some of these textures makes this a slow operation.

The reason why this happens now but didn't before is on account of a workaround for a bug fix elsewhere.

So - assuming that I'm right in my guesses - I can fix it; but I really need to know if I'm right before I proceed. 

I have windows 7, but no texture pack, my specs are in post 86. 

Is there a logging function in directq? maybe I can produce a log and sent it to you 

-condebug should work but I don't think it's going to be of any benefit. You've clearly got a bug that hasn't shown up during my own testing and that nobody else has reported (I've got other ATI users saying that it's smoother and faster than ever before, and my own benchmarks show it a consistent 1.5 times faster than the last 1.8.666) so it's definitely caused by something in your own setup or on your own machine.

So I need help from you to isolate the cause of this one, because everything on my side and everything on everybody else's side is pointing towards this being something that shouldn't even be happening.

Are you using any particular settings in your Catalyst Control Center? Anything to do with texture optimization or quality?

Have you any other programs running?

Are you overclocking?

Have you tried going back to a clean, default Quake configuration and seeing if it happens with that?

That's the kind of info that's needed now. 

just tested this out of curiosity and it is insanely slow. is there something i need to do to get it running properly? i seem to be getting about 10 or less fps in an area with 11k wpoly and about 6k epoly, no dynamic lights or particles effects.
this is on an nvidia gts250 and launched with the command line:
-heapsize 192000 -particles 20000 -nocdaudio -width 1600 -height 1200 +gl_clear 1 +scr_conspeed 32768 -bpp 32 

If you're finding it that slow then something is wrong with your machine or your setup, or else you've got a contrived scene or situation. I've a GT230 and I manage over 50 FPS with 17k wpoly and 30k epoly. With dynamic lights and particle effects. In an unoptimized debug build. And r_novis 1.

If this is an in-development map I'd be interested in knowing more as I'd like to figure out why it's slow. Because it most definitely shouldn't be. 

oh well, actually, it's slow like that for all maps.
arbitrarily picked e4m3:

noclipped out of the map, about 2.3k wpoly.
directFQ is about 15-19ms r_speeds
quakespasm is 1-3ms.

it has to be something to do with my machine though, i mean, i know the engine isn't *actually* that slow. i was hoping to figure out what does it though.

if it helps, this is on a dual-core cpu, w7 64bit system. 

15-19ms

Ahh, betcha vsync is enabled. Vsync behaves very differently between OpenGL and D3D, and D3D doesn't respect your video card's control panel settings. Or something; I'm not sure how it works in D3D8 which directFQ uses. 

OK, I get 16 or so ms with DirectFitz as well so it's not your machine, it's the code. Bearing in mind that the purpose of that port was stability on Intel cards rather than performance, it's OK.

DirectQ itself does 3-4ms noclip out, r_novis 1, sv_novis 1, 2846 wpoly and 27234 epoly. 

it's unfortunate performance takes such a huge hit, but thanks for clearing that up for me. 

Well I could probably do a lot to improve it, but it's not a live codebase anymore and I don't want to go hacking and slashing at the original Fitz code either; one of the objectives in those ports was to preserve the original code as much as possible. 

Hi mh, I noticed that since 1.8.7, directq some times have slight stuttering at certain parts of maps.

Another possible reason for this is that you may have CPU affinity set. DirectQ actually likes multiple CPUs and/or cores, and will prefer to use them if they're present. Setting CPU affinity screws this up and can cause exactly this kind of behaviour. 

It seems that RC3 no longer has this issue. Your changes must have fixed it.