Holy cow - by "unbuffered" i didn't realise we're performing a file-system open and close on every line written to console! No wonder there's problems. Hmmm... but tyrquake does it too, and i suppose others.

Anyway, i ran strace on quakespasm and tyr-glquake with
strace -ologtyr ./tyr-glquake -condebug +timedemo demo1
strace -ologqs ./quakespasm -condebug +timedemo demo1
which records all system calls.

Playing the demo, qs makes 666 (!) calls to "open", and tyr-glquake 218.
qs opens every file in the "quake" directory (probably checking for mods), which accounts for 83 "opens" on my box, but there's also a heap of qs-only opens which i think are related to the texture manager, and look like this

open("./id1/textures/cop3_4.tga", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./id1/textures/e1m3/wswamp2_1.tga", O_RDONLY) = -1 ENOENT (No such file or directory)
(except the forum is inserting some "..." here)

I guess it's something to do with the fitzquake texture manager, perhaps using a file system open ?? I've never played with strace before, so i could be mistaken about something too. 

I guess the extensions are .tga and maybe .jpg? Fitzquake probably checks if replacement textures exist for each texture in the current map load. I have no idea but maybe one could change that to something that does not try open right away but simply pings for an existing file? 

About how fitz dies on win 7, perhaps the delay is so long it's causing a server timeout or buffer overflow of some sort. 

I just tried it again and could continue/quit normally after the delay. 

I'm not sure it means anything actually. There's certainly a lot of extra "open" system calls - in the travail demo1 it's 275 for tyr and 1053 for qs and bakers fitzquake-sdl. But looking at ~when~ they're occurring, afaics they don't seem to overlap the repeated open and closes of qconsole.log. 

External textures need an open and close call to load, so that's probably it. Especially as I doubt TyrQuake supports external textures. The number of open calls is quite likely misleading here, as each open call isn't necessariy a success, and one that fails won't be leading to any consequent IO. Measuring the number of close calls would give you a better yardstick.

A possibly better solution for the condebug thing would be to buffer the text into main memory instead and only write it to disk when the memory buffer fills. Even a 1 KB memory buffer would remove a lot of the pain.

Still need to keep an unbuffered version for crash diagnostics though, and I say run with my suggestion of the cvar and "condebug 2" for that. 

Yup, that works. :)

We're down from a lockup of up to 10 seconds to almost instantaneous.

I use a buffer size of MAXPRINTMSG and copy text into that instead of writing immediately to file. When a new update would overflow the buffer I write to file then, and reset it.

When disconnected from a server everything gets written to file immediately. This handles the final necessary buffer flush when shutting down, and I reckon it's not so performance critical anyway.

condebug 2 or developer 1 will force the writing into no memory buffer and unbuffered IO mode. 

bit of a storm in a teacup anyway, laugh.

Buffering sounds feasible... but a little overcomplicated with condebug and condebug2 or whatever, because using buffered output will screw up with a program crash. Code ?

Would using windows redirection commands suffice... or is there an fsync for win32 ? 

It depends on what condebug is used for. If it's only used for crash diagnostics then it's perfectly fine to change nothing. But if it's going to be used for general-purpose logging of multiplayer games then obviously something more needs to be done. In any event the default behaviour should be what people expect it to be, and if people are complaining about stalls with it, then that's obviously not the case.

Does anyone even use it for crash diagnostics any more?

I don't think that creating a condebug cvar with values of 1 or 2 is necessarily a complicated thing. Certainly no more complicated than all the crap that you had to do to get WinQuake working on an old SVGA card for example.

Oh, and code: http://directq.codeplex.com/releases/view/42494 (all in console.cpp) 

Mehhmmmm... It's a bit of futzing around, but looks ok. Are you flushing the buffer when Sys_Quit ? 

No need to cos it flushes anyway when cls.state != ca_connected which will be true during a Sys_Quit. 

having some odd problems with fq085 in windows 7.
host_maxfps is set at 72, but the game runs too fast. i tried lowering maxfps to 60 and even 10, but the game plays at the same (too fast) rate.

my desktop res is 1600x1200x32 so i run the game at that as well. tried both fullscreen and windowed.

the game runs without compatibility mode, but i tried xp sp2 and sp3 mode but it didn't make a difference.

the exact command line is:
fitzquake085 -heapsize 192000 -particles 20000 -nocdaudio -width 1600 -height 1200 +gl_clear 1 +scr_conspeed 32768 -bpp 32 +developer 1 

is it multicore? Apparently there's a clock bug in quake (including fitzquake) which screws up the timer if the process switches cores (since the different cores have different clock speeds sometimes? not sure exactly.)

Some engines claim to fix this, including DirectQ and Proquake, though they seem to have different approaches to fixing it. 

weird, i never had the problem in winxp even though i had a multicore processor back then.
the win7 i'm using is 64bit though, and my copy of winxp is 32bit..?

am i SoL for fitzquake then? o.o 

well i'm not sure, here is the info i have found about it (assuming it's actually the problem you're experiencing):

http://mhquake.blogspot.com/2009/11/getting-rid-of-evil.html

Here's a possible workaround:

http://quakeone.com/forums/quake-help/quake-clients/3539-client-help.html#post44397

Another possible workaround is to tweak host_timescale to try to get the time back to normal (or at least close) ... 

also Quakespasm is based on fitz 085 and might have this fixed (it uses SDL, which has its own clock code i think...) 

Brief description of the problem here: http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=474

The relevant part is: "What QueryPerformanceCounter doesn�t understand, we�re finding out, is multi-core processors. On an Athlon64 X2 processor, QueryPerformanceCounter will sometimes report negative elapsed time, for reasons that are as yet unclear. One theory was that the timing code was being shuttled between the processor cores and that the cores� time bases weren�t always in sync. That might indeed be the problem, but just setting the timer thread�s affinity to a single core doesn�t appear to be the solution.".

Also more here: http://www.virtualdub.org/blog/pivot/entry.php?id=106

Using timeBeginPeriod and timeGetTime seems to be the way. You can test if these avoid the issues by running QuakeWorld, Quake II or Q3A on the same system: all of these use timeGetTime instead. 

Another good one here: http://jongampark.wordpress.com/2008/04/19/weirdness-of-the-high-resolution-counter-ie-queryperformancecounter/

"The 1st glitch is that the returned value easily exceeds the boundary of the 64bits for the QuadPart, because current CPUs are so fast."

DirectQ's implementation by the way keeps the returned value from timeGetTime as a DWORD for as long as possible, using that in all calculations and comparisons, and only converting to float when absolutely necessary. 

that definitely sounds like the problem, and i can confirm that just setting cpu affinity doesn't do anything.
i think the problem might have more to do with 64vs32 bit rather than dual core though, since as i mentioned, the problem was non-existent on a winxp 32bit system with the same cpu (core2duo 6300). 

i nabbed direct fitzquake, but it still has that timing problem, so i tried out directq, which does not. (quake3 didn't have the problem either, but the sound stuttered, including ioquake3) 

just wanted to also mention that quakespasm also was fine, so both directq and quakespasm are alternatives if you get the timing problem. 

Definitely QueryPerformanceFrequency and QueryPerformanceCounter then. I guess the SDL guys are well aware of the issues with them and used alternate approaches in the SDL timer.

Ironically the reason I did this in DirectQ was *not* to resolve the timer issue, but to deal with a completely separate matter (D3D manipulating the FPU control word). 

Thanks man, your engine worked perfectly for me and it made playing Q1 a pleasure again. Thanks for all the hardwork on this, awesome work :) 

glad to be of service :)

as you can see above, i still have some work to do :| 

i ran some mod via fitz085 and sometimes 'SV_TouchLinks: next != l->next' message popups

what is it? , i know this is somehow related to a teleporter,