ah, good to know. I can look at how they do it, maybe i did break something. 

> Well, it works flawlessly in GLquake and Ezquake for example. Winquake freezes, too.

That's odd because it's the same code in WinQuake as in GLQuake... 

On my linux C2D box, there's a noticeable delay, but nothing really. Day of the lords with 144/166 kills takes less than 2 secs with -condebug. Whatever it is, i think it's in quore-0.3.0 too, which uses some fitzquake code. 

1s here (athlon 2 x2 240). Exe: 16:04:11 Jul 5 2008 on Lunix. 

The original glquake generally would redraw the screen once for every line of text printed to console. For large dumps (like the edicts command) this took a long time, so I changed it to write everything first, then update the screen once at the end.

This is faster overall, but results in a small period of no screen redraws. Since in my testing it only takes a fraction of a second, I never saw this as being a problem. I suppose that with -condebug, it takes longer and this hang is noticable. However, the alternative is that printing 500 lines takes 500 render frames, i.e. like 5+ seconds.

I still haven't tested this so it may be there is some other dumb bug causing the lag. But that's my current theory. 

i guess there's some coding reason why you couldn't just make it print 100 characters at a time instead of all or nothing? 

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