ProQuake compiled with Visual Studio 2008 (9.0)

[sschm]

I typed the following messages on an invite-only Quake1 DM Google Group and lenny talked about contacting Baker and Rook about it:

Message #1: I do not know if it is considered to be a "hax" to compile your own client with compiler speed improvements, but I noticed a FPS boost with my version of ProQuake compiled with Visual Studio 2008 (9.0). The default PQ release is compiled with 6.0. I used PGO (Profile Guided Optimization) available since VC8.0 (2005) to fully optimize the binary. I also compiled libcurl and zlib with the modern compiler.

There is a problem with ProQuake in XP when using CPUs that have more than one core, but I found a program called RunFirst which solves all
of the issues I have had with ProQuake in Windows XP. The following ZIP archive has the optimized GL ProQuake binary and libraries along with my updated configuration: http://www.mediafire.com/?7a7djyl95msoqdg

I managed to get 20-40 more FPS in some timedemo tests with this binary. I know many of you are not using GL ProQuake, but if you are, maybe this will benefit you.

Killing Time replied: hacker! banned! the code is not multi-core aware so the os will always run it on an arbitrary core or did it crash and you needed runfirst to make it work ? rook - i hope you're using this compiler with your latest exe's

Message #2: When I launch it the game is very choppy. The FPS drops below 100 sometimes! But, when I set the processor affinity with Windows Task Manager to use only one CPU, the problem goes away and I instantly have improved FPS in ProQuake. The problem with doing it manually like that ... well, it gets old quick, and the problem with ProQuake hanging on me when I try to exit is no longer present while using RunFirst. RunFirst automatically assigns only the first CPU to be enabled for any program you run with it.

Lenny replied: I hear that making it use only one core increases fps a lot. Try MH's directq if you really wanna boost your performance. I don't use it because I don't know anyone with a cfg for it but maybe you can just put one together. I hear it runs really well

Andy Xiong replid: I can get upwards of 10000 fps in DX8 Quake.

Message #3: In my version of PQ, libcurl and zlib has been updated to the most recent versions as well as compiled with VC 9.0 WPO. The public version of Qrack is compiled with VC 9.0, but I am not sure if whomever compiled it attempted to utilize the new PGO (Profile Guided Optimization) feature of that compiler.

FWIW, those new libraries might not do a damn thing to benefit you, but even if you use Qrack, the public release is using outdated libraries that have been compiled with MSVC 7.1 (libcurl.dll) and MinGW 2.56 (zlib1.dll, now renamed to zlibwapi.dll in newer versions). You should be able to snatch the updated libraries and replace them for use with Qrack.

Lenny replied: I don't know anything about this stuff what so ever but rook does qrack. He plays on the server late at night although he hardly uses the alias rook. Baker does pro quake. You could contact both of them at quakeone.com if you were interested.

[Baker]

the code is not multi-core aware so the os will always run it on an arbitrary core or did it crash and you needed runfirst to make it work ? rook - i hope you're using this compiler with your latest exe's

Yeah, as I understand it from things Spike and MH have said, Quake can't realistically be multi-core. The QuakeC interpreter is one reason.

Message #2: When I launch it the game is very choppy. The FPS drops below 100 sometimes! But, when I set the processor affinity with Windows Task Manager to use only one CPU, the problem goes away and I instantly have improved FPS in ProQuake.

Maybe something can be done about that. I haven't personally experienced that problem, but I'm against the idea that someone has to tweak operating system settings or mess with the task manager for the engine to run as best as it can.

I haven't experienced that on Windows Vista or Windows 7, but anything that improve stability is important.

Thanks for all that comprehensive information on how you improved performance. I thought it was funny seeing the name "sschm" in the server browser a couple of weeks ago and was thinking "Hey, the Oil For Quake Servers guy really exists!"

(Those servers were really helpful back when NetQuake was hanging by a thread and they ran custom maps Not that the player base at the moment is large or anything but now it has support, places to promote it, an information infrastructure and places to ask for help and present ideas. The OFQS servers were the only non-Chicago/Texas HDZ places to play CRMOD for quite a while.)

[Lerster]

congrates for compiling your own quake.

It took me along time to do that, and i needed assistance to even get it to compile.

However.

Just remember the golden rule: "The better you think it is, the worse it gets."

In short, it may be running faster, but you may of created lots of bugs, by optimizing it with a VC compiler, since quake was built in C but, also was built with assembly to make quakeC language... less you optimized the proquake source that exists out there that had all the assembly files removed.

An even still, you may have created more bugs by getting ur fps gain. Only time will tell, of course.

:p

I don't personally care about fps increases... but, still congrates on your progress and thanks for sharing.

An yes i use only proquake as my client of choice.

[monoz]

dm players have a super secret forum!! dont forget the decoder rings. dm is so fucking gay. lol

[R00k]

What does this have to do with compiling proQuake?

[Bruce2]

I agree rook.

Baker thanks for the news post.

I was a long time supporter of pq and your efforts until you went Mia and found rook here to cuddle me and spoon feed me qrack to make me feel better.

I appreciate both of your efforts and wish I had the time to contribute.

Well I am but via iPhone app

[Bruce2]

Oh. Sorry to hijack. Thanks sschm for the efforts and binaries.

[Spike]

But, when I set the processor affinity with Windows Task Manager to use only one CPU, the problem goes away and I instantly have improved FPS in ProQuake

This is often caused by some piece of software using the 'rdtsc' instruction (typically via QueryPerformanceCounter). Certain CPUs, most famously dual core AMD ones (but not hyperthread fake-dual cores, though some intel dual-core setups are affected), update their internal timestamp counter at a rate related to the internal clock. This is problematic when the internal clock varies slightly from one core to the next. Things that can affect that internal clock vary, but the main cause is the internal clock simply not ticking if the cpu core has nothing to do.
This means that when the OS task schedular shifts the process from one cpu to the other, your timer values can jitter from one core's value to the other. One possible result is that, assuming vsync is on at 60hz, you have one frame that appears to take 1/30th of a second, and one frame that appears to take no time at all to run. This makes it quite choppy, and anything that measures framerates can get confused.
This particular issue has been resolved on modern cpus by syncing the timestamp counter to the system bus instead of the internal cpu clock, so all cpus will tick over at the same rate, independant of actual cpu power saving profiles.
QuakeWorld engines tend to use timeGetTime instead, which avoids all such issues on all versions of windows, but has lower precision. Use of which should remove the need to set affinity, which means hidden threads created by directsound or other libraries are not forced to share the same single core as the main engine thread.

Regarding threading - you can't thread the gamecode against its wishes, but there's no reason you can't use threads in the engine code. Candidates that come to mind are sound (_snd_mixahead no longer needs to cover slow rendering and can thus be lower) and lightmap updates (because large dlight/lightstyle updates result in uneven frame timing). Other things, like model loading, server logic, and dns lookups are also candidates but are less useful or more involved.
The main annoyance is likely cvar values changing mid-function, and that you might need some mutexes in certain sections of code (like console+memory).

If msvc's profile-guilded-optimisations appears to cause a bug, then its quite likely that the bug was already in the code and gcc would have tripped up on it too. Optimisations should not be considered a cheat unless its noticably buggy, if you claim that they are then you must also claim that using anything more than a p300 is a cheat, and thats being generous.
That said, any anti-cheat stuff or tournaments that require specific builds will generally frown at you, as a self-compiled build is indistinguishable from one someone (hyperthetically) added some aimbot to.
This is my personal opinion, of course, and others may think differently.

[MH]

Beware of threading where the overhead of thread-syncing is higher than the gain from being parallel.

Sound is the only real candidate that comes to mind CPU-wise. Now that I have a working D3D11 renderer I'm planning on threading that and seeing what happens. I suspect that MDL drawing will be an initial candidate, although I also suspect that Quake's GPU overhead per-object is so low that it won't matter much either way.

All engines should use timeGetTime - so many problems just go away. I've an i7 and QPC code just goes nuts on it, so the problems with it are not resolved yet.

Another downside however to timeGetTime is that you'll run at 71fps instead of 72 (it's actually ~71.4fps). That's resolvable by reworking Host_FilterTime to add (1.0 / 72.0) to realtime (which remains a double) as the time for the next frame to run at, then checking the current realtime against that. Pass total milliseconds elapsed so far since the engine started to Host_Frame (and Host_FilterTime) rather than a frame delta time. realtime then becomes this total * 0.001 rather than an accumulation of frame delta times (which is a rather nasty way to count up time on a PC), and host_frametime is the current value of realtime - the value of realtime at which a frame last ran.

[sschm]

Thanks for the follow-ups.

I have used rdtsc for use in coding random number generators and I have used QueryPerformanceCounter for numerous things, but in most recent memory for getting around the 49 day limit that is encountered with GetTickCount.

The system I am running Quake on is a bit outdated (2006), and the CPU is an AMD64 X2. This explains the performance problems I have encountered. Multi-core technology was just taking off during that time period. Since the only game that I sometimes play is Quake1, there has not been any need to update the system that I play it on. 750fps in timedemo is plenty enough, and, if I remember correctly, it is capped at 72fps in QW.

I am not an anti-QW fanatic like many NQ players are, and I think the speed hoping in QW is a unique experience. I can speed hop around the maps in single player Quake at blazing fast speeds like you can in QW, but while connected to a NQ server, speed hoping becomes less effective but still doable to a lesser extent.

[R00k]

~SIDEBAR~
NQ players are not anti QW, but the maps that were created imho, were not made for those speeds. Dm it self is a management of item timing, not just when something will spawn but how long it will take you to get from ya to pent, to quad to RA to mega back to rl. QW speeds is like adding a Hook to nq dm. too much leniency to the grab and go and thus offsets what most players are used to.
Personally not to get on QW digg, I STILL dont like the jittery look of players/projectiles of QW. NQ is fine (at sub 50 ping), but everytime i try to give qw a shot, players skip around like a bad connection and my shot seems like it happens 2 seconds after i mash the button, blah all the other bells and whistles of QW are crippled but the non fluid motion of entities. Tonik once sarcastically asked "More nq players would play qw if it had better interpolation??!" Maybe, but im not gonna play a predicted protocol if its not consistent, and interpolation hides that inconsistency atleast in NQ.

[sschm]

Not to make this thread off-topic, but I will put in my opinion about what R00k said:

They also turned deathmatch mode 3 on (at least for 1v1), thus making all of the weapons static (no need to time them). The speed hoping requires learning and it is a skill that is developed over time. I doubt if most NQ players can speed hop like the best players in QW. I agree that the developers of this game and its maps did not intend on the players being about to move around at such speeds, which is unrealistic to begin with. One of the things that I like about NQ is that it is "old fashioned." I might like the old game style that we used during the years 1996-2000 more than the new style introduced in QW at a later time. I have developed the skill of speed hoping on all of my favorite maps, but I would rather play the old style.

[R00k]

True, CTF has a blended component of that. You actually get to USE airstrafing!!! So I can appreciate the physics. But playing Ctf -qw pfft.. u can out hook/bunny most rockets.