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, 

This one by any chance?

http://forums.inside3d.com/viewtopic.php?t=1431&highlight=engine+killing+teleporter 

I saw that message, too, a couple of times and wondered what it means. For apparently, it's not THE sv_touchlinks issue, the one that crashes unprepared engines (like in E2M2). Check the pent secret in my coag map for reference. 

it's a fix for what mh linked to.

However this fix ended up being a problem because it crashes White Room, so i need to figure out how to fix it correctly for my next release. 

My implementation of the more robust fix is here: http://forums.inside3d.com/viewtopic.php?p=23987#23987

Works with both proxmap2 and whiteroom. 

Seems like the issue doesn't always necessarily lead to a crash/freeze then. 

Depends on the QC. Apparently calling remove while touching links is what can cause the lock-up, but no doubt it's possible to construct QC that does other lesser but still nasty things. 

It seems like quite a dangerous restriction on the qc, because a lot of the time you're writing code for which you have no idea if it's going to be run in a touch function or something safe like a think function instead. For example, a death function might get called from a collision or a hitscan attack originating from playerpostthink.

Still, it's nice to think that the original QC authors have made sure to take this instruction to heart. They would never call remove directly within a function used as a touch function, Especially not one as common and clearly labelled as spike_touch

Oh, wait...

In conclusion, I'd guess that removing one of the entities involved in the collision is generally safe, and it's when you start removing 3rd party entities that the problems arise. Can anyone who understands the e2m2 crash better than me confirm or deny that? And would making sure killtarget uses SUB_Remove on a short-delay think fix that case? 

I'm not certain that I'd see it as a restriction on QC, but more a case of QC authors either not knowing their tool or not testing well enough. It's possible to write software that crashes in any language, and QC should be no exception. If writing in C for example I'd conform to the rules of the language, and not expect something I write to always work just because I wanted it to.

If it breaks in ID Quake then by definition it's broken is my opinion, and this one breaks in ID Quake.

I think the short-delay think sounds like a good idea, but my own QC knowledge is quite limited. 

What I'm saying is that it's virtually impossible to write QC which guarantees it doesn't remove things during touches - calling that a case of QC authors either not knowing their tool or not testing well enough. is disingenuous. A mapper could potentially apply any function in the progs as a touch function to an entity, including SUB_Remove.

Even if you argue that this one is the mapper's fault, that's just the least subtle problem. When I cited the example of a death function which could be called from both touch and non-touch functions, the important thing to note is that the two cases are indistinguishable from the QC. There's no flag you can read, and you can't create one yourself because any function could be made into a touch somewhere.

If you were willing to compromise some responsiveness in removing entities and guessed at the most likely circumstances, you could probably reduce the amount of "remove during touch" by 90% compared to the original progs. But totally preventing it on the qc side isn't just a case of a little bit of care - it's so hard I don't even know if it's possible. 

Here's what's used in quakeworld clients like Zquake, that I've used in Qrack with 64bit windows 7 without any problems.

/*
================
Sys_InitDoubleTime
================
*/
void Sys_InitDoubleTime (void)
{
timeBeginPeriod (1);
}

/*
================
Sys_DoubleTime
================
*/
double Sys_DoubleTime (void)
{
static DWORD starttime;
static qboolean first = true;
DWORD now;

now = timeGetTime();

if (first)
{
first = false;
starttime = now;
return 0.0;
}

if (now < starttime) // Wrapped?
return (now / 1000.0) + (LONG_MAX - starttime / 1000.0);

if (now - starttime == 0)
return 0.0;

return (now - starttime) / 1000.0;
}

Hope this doesnt reitterate what someone else said as I didnt read the whole thread :P 

i think it's great to raise awareness of this issue as more of us pick up dual (or more) core processors and 64 bit operating systems. 

regarding this feature from the readme:

- god, noclip, notarget, and fly can now be explicitly set. example: "god 0" will disable god mode

how possible would it be to make cheats, specifically notarget, be enableable from the command line? ie, by adding +notarget 1 to the end of your batch file or whatever so the map loads with it turned on... unless i am missing another way to do this?