News | Forum | People | FAQ | Links | Search | Register | Log in
Fitzquake 0.85 Released At Last!
New in this version: increased map and protocol limits (can load all known limit-breaking maps,) model interpolation, per-entity alpha support, new network protocol, more external texture support, hardware compatability improvements, many bug fixes, and a cleaner source release to make it easier to install and compile.

Go! http://www.celephais.net/fitzquake

(Thanks to the beta-testers: Baker, JPL, negke, Preach, and Vondur.)
First | Previous | Next | Last
 
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) 
Triple Posting, Sorry 
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). 
Metlslime 
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 :) 
Sock: 
glad to be of service :)

as you can see above, i still have some work to do :| 
Metl 
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, 
The Mysterious 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. 
Spy: 
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. 
Remove 
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. 
Challenge 
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. 
Timing Issues 
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. 
Cheat Commands.. 
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? 
Rj: 
have you tried it? It sounds like it would work. 
Alas 
yes, and no.. 
Rj: 
try the different possible orders of command:

+map e1m1 +notarget
+notarget +map e1m1

I'm not sure which order things are executed from the command line, it might be reverse order. And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work. 
 
And since i think "notarget" etc. gets reset at map load, that might be the reason it doesn't always work.

yeah that's what i figured. neither combination works (whether it has a '1' after it or not)

say i wanted to make it function like 'skill' - ie, carryable across maps, would that be qc-side or engine-side? 
 
+notarget +map e1m1 works ok on WinQuake. Best way however to make something carry across maps is to use the changelevel command instead of map. Unfortunately changelevel needs an active server to carry over state from so it won't work on the command-line. 
Running Fitzquake 
I need some help. When I try to run fitzquake it says it could not load gfx.wad I don't know what that is or what I should do does anyone know? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.