probably the whole system needs to be re-thought. Quake has some weird linkage between console updates and screen renders which doesn't make a lot of sense; I think the original motivation was when you are disconnected there is no map rendering to trigger a screen redraw, so the console printing needs to do it.

Really we should just redraw the console at a fixed rate when disconnected, and then printing doesn't have to be linked to drawing. 

I'm just curious as to the reasons why someone would want -condebug on all of the time. I suspect that it's not intended for this kind of general use (the presence of "debug" in the name kind of gives that away...) so it shouldn't really be considered performance-critical.

Seems to me that people might be using it to keep a log of events in a multiplayer game rather than it's intended purpose (checking console messages immediately prior to a crash - see the Quake readme) so maybe switching it to buffered I/O as a default is the way to go.

I'd suggest adding a "condebug" cvar, so it can be toggled if it causes trouble. Value 1 uses buffered I/O, value 2 uses unbuffered I/O. Also use unbuffered I/O if developer is 1. You can keep -condebug on the command-line, check it at startup and set the appropriate cvar value if you wanted as well. 

...that the edicts command is a pathological worst-use-case as well. Expecting performance from it might be a little bit unreasonable.

And also that it's actually quite important for the intended use of condebug that it be unbuffered and write each line individually, otherwise you might not get the console message indicating what caused the crash. 

I'm just curious as to the reasons why someone would want -condebug on all of the time.

Multiplayer stats. Sometimes people want to log all the console output, and use an app/script to parse the logs for death messages or whatever (to generate a breakdown of kills, deaths etc).

Just one scenario where you may want it enabled all the time. 

Non trivial disk accesses are best left to the OS anyway.
One way with linux is "fitzquake | tee FILENAME", which duplicates stdout to a file. Neg_=!ke's worst case was with Win7 too.. which may still have the occassional disk performance issue, ala vista. Just out of curiousity, Negke - in win7, shut down everything which uses sound, run fitzquake with -nosound, and see if there's any improvement.

Still, 40 seconds on XP indicates there is a problem. Hmmm... I just tried a 170 enemy map by tronyn. Linux - 2 secs, XP - 7 secs. Perhaps it's the crappy vfat filesystem, which performs really bad when it's getting full ? 

I don't have it enabled all the time. It's only to get a copy of the edicts list - when looking for modelindex values, for example. The condump command often doesn't help here because of the console text limit.

stevenaaus: still freezing with -nosound, too. 

> Multiplayer stats. Sometimes people want to log all the console output, and use an app/script to parse the logs for death messages or whatever (to generate a breakdown of kills, deaths etc).

That's what I kinda suspected, and supports the case for changing it to buffered by default. 

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.