Oh, does this mean the Fitzquake can't support Neh fog? (Aguirre's can support both, but that engine, like Nitin said, isn't widescreen friendly) 

When I ran directq 1.8.7, it looked like this:

http://www.quaketastic.com/upload/files/screen_shots/Directq_187_bug.jpg

I have the June 10 version of Directx, My system is a Dell XPS 1640, 4gb ram, p8400, ATI 3670 with 10.6 drivers.

Directq 1.866b works perfectly. Thanks. 

http://www.quaketastic.com/upload/files/screen_shots/directqbug2.jpg 

Thankfully it's a beta release...

A few people have got this bug and it seems confined to ATI users. I've a good idea what causes it and will have a fix coming in Beta 2. 

When you start a map, you're not facing straight fowards. Seems to happen with any map. 

Doesn't happen with any of the ID1 maps. Can you be more specific? 

http://www.quaketastic.com/upload/files/Menk.jpg

This is how I start at Menk. I've tested Fort Driant, and ijed's Maelstrom. All like that.

This bug does not happen if you load the map from the cosole, only via a batch file.

My batch file for load Menk:

directq -nocdaudio -current -game id1 +map Menkstart -id1 -bpp 32

This bug did not exist in 1.866b. Thanks 

Also affects Nehahra too 

It also happens in 1.8.7 beta 1, so it is the changes between 1.866b and 1.8.7 beta 1 

Got it, thanks. 

Directq 1.8.7 beta 2 crashes when I run Five Rivers Land by JPL

this is my commandline:

Directq -nocdaudio -current -hipnotic -game quoth -heapsize 48000 +map 5rivers_e1 -bpp 32

said something about Directq being toast.

Directq 1.866b worked fine. 

5 rivers has corrupted TGAs for it's skybox which D3D's TGA loader doesn't like. A fix I had before was bypasssed by some of the new code. 

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.