Some folks don't want the jittery gameplay that comes from running ip scripts, frameskippa, or running without triple buffering in the case of vsynched players. In that case there are some steps one can take to make the game smoother.
One is a gem from Tribes original flavor;
$pref::AnimateWithTransitions = 1;
This forces the game to interpolate between frames full time, in a client case it makes the play smoother - turrets, force fields, and players move fluidly and more realistically, when used on a server it can reduce nonregs and make the game much more "accurate" - no more slop in flag grabs, you best be right on top of it - not a meter one side or the other from it. Running this serverside will piss off "vets" who have been playing slop for decades and suddenly find they have to actually make contact with a flag or aim to hit someone. This string goes into your clientprefs.cs for clients, and serverprefs for servers. The 1 at the end means enabled, a 0 disables it. While on the topic, the reason T1 script works in T2 is the game engine for T2; Torque, is derived from that of T1; Darkstar, with much the same scripting language and many other similarities, I imagine most of Darkstar is inside Torque. Needless to say if there's a T1 script you'd like to run in T2 it will be easy to edit it into operation, and vice versa. I edited frameskippa, a T2 script, to work in T1, for one example.
Another game smoothing string is;
setPerfCounterEnable(0);
This string has long been a boon to those who have more than one cpu, it also works client or serverside and can be popped into the same locations as the above string. Some systems will actually run smoother with it set to 1 so try both ways.
Some people run the game at a non native screen resolution; this will cause lag as either the gpu, the monitor, or both are trying to scale the resolution to whatever the user specified, always run native res if you can.
A common mistake is running the game in multi thread mode, this is set via your vid card game profile in your vid card control panel, make sure tribes is set to single thread mode in nvid cards case it's called threaded optimisation mode, set it to disabled for T2. While this setting has always been disabled in any nvidia card system I ran, it worked great in ATi/AMD vid cards and gave a noticeable improvement in gameplay smoothness.
If you run vsynch you should also enable triple buffering - found in the vid card control panel/game profile - this can greatly smooth things out in game as there should always be a buffer ready to be painted, displayed, or discarded if gamestate in that frame is stale. As the name implies, there are three frame buffers instead of the usual 2. In some cases triple buffer can cause a bit of input lag but that should go unobserved for the most part.
If you run ip scripts, frameskippa, or the like, you're going to have to live with a stuttery game as that is the price of running those scripts, no way around it.
So the other day the rest of the pc, the game system that had the drives go south a few weeks back, went south to catch up with the drives. Mobo was acting flaky with random glitches and finaly refused to boot past the bios splash screen, my guess is ether a chip failure or bios corruption issue. This warranted at least a different mobo but perhaps not a cpu.
I didn't want to spend money on a system that would spend its life playing T2, so used and on hand parts were the only solution.
Wanting to use the same case, psu, cpu, mem, and drives I looked at the various systems on hand that parts could be cannibalized from, two prospects immediately arose. I selected the Supermicro mobo and already installed cpu, said cpu having more cores than the old game system but said cores ran a few hundred mhz slower. In a benchmark video I saw these old multicore cpus were actually pretty competitive with todays cpus in certain apps, as long as they had more than 2 cores.
Supermicro builds some of the highest quality mobos in the biz, mostly for datacenter/server use and high reliability stuff like gov and research.No ocing options in Supermicro stuff. I originally wanted to use that mobo and cpu for dsp and audio work but the other proposed system was almost identical in specs save for its mobo being an intel oem, so that one will be the dsp box.
So the cases were emptied of mobos and cpus, the bad parts tossed, new parts dropped in, and then I wondered if a fresh coat of win7 would be needed - meaning hours of os install and updates, I left the original drive from the failed sys in the case and connected it to the new mobo, not really expecting it to take off and boot into windows but it did.
The new mobo is a generation newer than the old and of course the cpu was entirely different, but the vid card was the same one from the game system. Needless to say I was very surprised and pleased to see windows boot and ask to do a repair for the missing drivers and so on. Allowing it to update itself got it back to a perfectly running win7 install and T2 runs fine, never had to add any drivers or anything. That said, did have to reactivate win7 and wondered if ms would allow it, for some reason it said I only had 2 days to do the activation, I thought what the heck try to activate right now... and it did.
In the old days (2k, xp etc) it was kinda hard to note a performance increase from going from one cpu to mulicore, unless one always had multiple apps running or a demanding app that was mulithreaded - wich would dog a single core. Todays os are much better at spreading threads to keep cores busy and make a noted improvement in overall day to day performance. Hopefully this build will last a few years, the old one was built from new parts in 2008.
More related to T2, the game only takes around 160 megs ram in use, and todays vid cards can keep high frame rates even with maxed out antialiasing and aniso filtering at resolutions the T2 devs likely never considered. The onboard audio and vid of the current crop of cpus and mobos don't even know T2 is running, unlike with the systems prevailent when T2 came out; T2 routinely crushed powerful gaming systems of the day. Have 30 players in camera all flying around and firing at each other and your gf4ti would come to a crawl even without aa or aniso enabled.
When building a server recently I noted some online discussion of add in nics (network interface cards) as opposed to onboard with respect towards reducing cpu use. Some say onboard is fine if a decent chip is used by the mobo maker, others give examples of reduced cpu use with decent add in cards. I have used onboard for the most part if they were marvel or intel chips, but wondered if there'd be any worthwhile performance improvement by going add in, I found some anecdotal evidence to affirmative. One user had a server with onboard nics and he employed them as that is what he had, when he obtained a intel pro1000 pcie server nic he installed it and did some back to back testing. In these tests he saw a reduced max throughput (103 to 87mb) but a greatly reduced latency for all transactions. Order of magnitude, meaning big, like going from 100ms or more to only a few ms, and that is where my ears perked up. Reduced latency is what online twitch gaming is all about. Oddly enough I have the exact mobo chipset and add in nics as this user, and seem to be getting similar results.
Audio
One example relative to my case was a user who noted 17 percent cpu use simply viewing a youtube vid with onboard sound, going to a sb live card got him down to say 10 percent cpu, going to an audigy 2zs (a very old card by todays standards) got him down to 2 percent. I had a audigy 2 around here for some time but never tried it, popped it in today and it's working fine. Some glitches noted when watching vids or gaming seem to be greatly reduced, even though no sound cards are hardware acceleration anymore - all are cpu driven, apparently some are better than others.
As to Placement, here's the why and how;
Consulting the mobo manual revealed the block diagram of the chipset showing wich pcie lanes were where and how the pci lanes were laid out and who they connected to - the cpu or the northbridge chip (in the case of this intel system). Most everything onboard; sound, vid, net, is all going thru the northbridge. What I decided on was to place each major component on its own bus (pcie, pci, or straight to the cpu), as per the mobo manual.
The nic is a pcie server card with a pcie8x formfacter. The only free pcie slot was directly under the gpu but since the card's tiny figured there's no problem with it blocking cooling of the gpu. The gpu, on a pcie16x bus, has its own link directly to the cpu. So there's the nic sorted.
On the sound card, I noted that pci lane 1, the very bottom pci slot, was all alone on its way to the northbridge, sharing the bus with nothing else, bingo, there's the slot to use.The bottom slot also put if ar away from notorious noise makes like usb lanes and psu trash.
So far so good, only had to find a driver for the sound card, win7 had the driver for the nic.
The idea is to have every major component on its own bus, and that has more or less been achieved in this instance.
It's still old crap pc parts no one wants or uses today, but I'm wringing all the fps I can outta them.
It used to be easy to get smooth gameplay when all we had was one cpu core. Now the core counts are ever increasing while most older games, T1 and T2 included, are single threaded and at the mercy of the scheduler of any given os. A thread is that part of a program that gets executed by a core - ie math. A scheduler more or less is the part of the os that decides what thread gets run and when and it's trying to keep some cpus running over 3GHz busy.. This paradigm presents a serious problem in some cases, especially where the scheduler moves a single threaded game to any core not busy at the time time the thread's scheduled to run. That movement entails a lot of behind the scenes chicanery as the cache is flushed and filled with new contents on the current core, and the core the game thread just departed does likewise. All of that takes time, almost an eternity in the view of a cpu. Sure the game still runs on an smp sys, but oddities like audio glitches and erratic fps can be noted, expecially in the case of T2. Things would be smoother in gameland if a smp system kept threads to the same core as much as possible, and not just in gameland. Newer games are typically coded to ensure smp poses no problems and even increase performance of the game.
When NT came along it had a kernel that was smp aware and will make use of multiple cpus, but had a FIFO or first in first out scheduler. That means whatever the scheduler ordered the memory to load into cache was booted out by the contents of the next cache order, even if the former was more desirable - from a performance standpoint - than the latter. This was followed on by 2K wich had a LRU cache methodology, meaning the least recently used cache contents gets flushed - but only when a single core was present, in smp 2K was FIFO, so 2K's a more polished NT but with the same smp scheduler more or less. Then came XP, with a LRU algo running the cache in smp or up (uniprocessor) systems. But XP still would cache thrash in smp since the scheduler wasn't a per processor runqueue type, a per processor runqueue tries to keep the same thread and cache in the came core in an smp system. The per processor runqueue was fielded by M$ in Server2003, then Vista, and is present in all M$ os since far as I know. That said, things are better, but threads are still thrashed even in an per processor runqueue, just to a far lesser degree.
When all we had was 2 cores it still wasn't so bad with cache thrashing, as the malady was coined, and easily dismissed, but with more than 2 cores it becomes something that cannot be ignored visually, not only that, it can reduce performance.
So what's the solution?
I recently went from a 2 core game sys to one with 4, and at times the game would actually drop below 30fps, something that never happened with the same hardware (other than the cpu) in the old sys. I presumed correctly it was due cache thrashing, as employing a batch file that set the affinity to a single core for the game showed, now not only is there creamy smooth gameplay but the well known audio glitch when using the jets is eliminated.
This thread got my attention when looking for lag inducers;
"Recently, a youtuber named 'Tech Yes City' did a comparison Video between Windows 10 vs Windows 11 and found out that W11 has more latency.
It's pretty interesting to see what he tested. He specifically compared TPM, Secure Boot on vs off and saw a 3ms reduction in Lag (mouse movement to photon delay), just by disabling these settings inside bios.
Also, he showed that disabling backround services and tune/debloat windows does make a big difference for Latency, no matter which windows version.
I'm happy to see someone finally testing these things, because it was in debate that these settings decreases lag."
I eventually learned what services were safe to disable or set to manual and still have a working system, after much anguish, lol. A XP Services guide was handy for starters;
This thread is a goldmine! I'm glad you are still updating it years later. Also, as someone who is currently playing T2 on Linux, I would recommend that as an alternative to W11. It works very well. Anyway, I hope you don't mind me including this thread in my next Tribes 2 Content Pack version, as it contains a lot of good info.
Comments
A Word on Smooth Gameplay
Some folks don't want the jittery gameplay that comes from running ip scripts, frameskippa, or running without triple buffering in the case of vsynched players. In that case there are some steps one can take to make the game smoother.
One is a gem from Tribes original flavor;
$pref::AnimateWithTransitions = 1;
This forces the game to interpolate between frames full time, in a client case it makes the play smoother - turrets, force fields, and players move fluidly and more realistically, when used on a server it can reduce nonregs and make the game much more "accurate" - no more slop in flag grabs, you best be right on top of it - not a meter one side or the other from it. Running this serverside will piss off "vets" who have been playing slop for decades and suddenly find they have to actually make contact with a flag or aim to hit someone. This string goes into your clientprefs.cs for clients, and serverprefs for servers. The 1 at the end means enabled, a 0 disables it. While on the topic, the reason T1 script works in T2 is the game engine for T2; Torque, is derived from that of T1; Darkstar, with much the same scripting language and many other similarities, I imagine most of Darkstar is inside Torque. Needless to say if there's a T1 script you'd like to run in T2 it will be easy to edit it into operation, and vice versa. I edited frameskippa, a T2 script, to work in T1, for one example.
Another game smoothing string is;
setPerfCounterEnable(0);
This string has long been a boon to those who have more than one cpu, it also works client or serverside and can be popped into the same locations as the above string. Some systems will actually run smoother with it set to 1 so try both ways.
Some people run the game at a non native screen resolution; this will cause lag as either the gpu, the monitor, or both are trying to scale the resolution to whatever the user specified, always run native res if you can.
A common mistake is running the game in multi thread mode, this is set via your vid card game profile in your vid card control panel, make sure tribes is set to single thread mode in nvid cards case it's called threaded optimisation mode, set it to disabled for T2. While this setting has always been disabled in any nvidia card system I ran, it worked great in ATi/AMD vid cards and gave a noticeable improvement in gameplay smoothness.
If you run vsynch you should also enable triple buffering - found in the vid card control panel/game profile - this can greatly smooth things out in game as there should always be a buffer ready to be painted, displayed, or discarded if gamestate in that frame is stale. As the name implies, there are three frame buffers instead of the usual 2. In some cases triple buffer can cause a bit of input lag but that should go unobserved for the most part.
If you run ip scripts, frameskippa, or the like, you're going to have to live with a stuttery game as that is the price of running those scripts, no way around it.
A Word on Cheap Game Systems and Crash Recovery
So the other day the rest of the pc, the game system that had the drives go south a few weeks back, went south to catch up with the drives. Mobo was acting flaky with random glitches and finaly refused to boot past the bios splash screen, my guess is ether a chip failure or bios corruption issue. This warranted at least a different mobo but perhaps not a cpu.
I didn't want to spend money on a system that would spend its life playing T2, so used and on hand parts were the only solution.
Wanting to use the same case, psu, cpu, mem, and drives I looked at the various systems on hand that parts could be cannibalized from, two prospects immediately arose. I selected the Supermicro mobo and already installed cpu, said cpu having more cores than the old game system but said cores ran a few hundred mhz slower. In a benchmark video I saw these old multicore cpus were actually pretty competitive with todays cpus in certain apps, as long as they had more than 2 cores.
Supermicro builds some of the highest quality mobos in the biz, mostly for datacenter/server use and high reliability stuff like gov and research.No ocing options in Supermicro stuff. I originally wanted to use that mobo and cpu for dsp and audio work but the other proposed system was almost identical in specs save for its mobo being an intel oem, so that one will be the dsp box.
So the cases were emptied of mobos and cpus, the bad parts tossed, new parts dropped in, and then I wondered if a fresh coat of win7 would be needed - meaning hours of os install and updates, I left the original drive from the failed sys in the case and connected it to the new mobo, not really expecting it to take off and boot into windows but it did.
The new mobo is a generation newer than the old and of course the cpu was entirely different, but the vid card was the same one from the game system. Needless to say I was very surprised and pleased to see windows boot and ask to do a repair for the missing drivers and so on. Allowing it to update itself got it back to a perfectly running win7 install and T2 runs fine, never had to add any drivers or anything. That said, did have to reactivate win7 and wondered if ms would allow it, for some reason it said I only had 2 days to do the activation, I thought what the heck try to activate right now... and it did.
In the old days (2k, xp etc) it was kinda hard to note a performance increase from going from one cpu to mulicore, unless one always had multiple apps running or a demanding app that was mulithreaded - wich would dog a single core. Todays os are much better at spreading threads to keep cores busy and make a noted improvement in overall day to day performance. Hopefully this build will last a few years, the old one was built from new parts in 2008.
More related to T2, the game only takes around 160 megs ram in use, and todays vid cards can keep high frame rates even with maxed out antialiasing and aniso filtering at resolutions the T2 devs likely never considered. The onboard audio and vid of the current crop of cpus and mobos don't even know T2 is running, unlike with the systems prevailent when T2 came out; T2 routinely crushed powerful gaming systems of the day. Have 30 players in camera all flying around and firing at each other and your gf4ti would come to a crawl even without aa or aniso enabled.
A Word on PC Parts Selection and Placement
Networking
When building a server recently I noted some online discussion of add in nics (network interface cards) as opposed to onboard with respect towards reducing cpu use. Some say onboard is fine if a decent chip is used by the mobo maker, others give examples of reduced cpu use with decent add in cards. I have used onboard for the most part if they were marvel or intel chips, but wondered if there'd be any worthwhile performance improvement by going add in, I found some anecdotal evidence to affirmative. One user had a server with onboard nics and he employed them as that is what he had, when he obtained a intel pro1000 pcie server nic he installed it and did some back to back testing. In these tests he saw a reduced max throughput (103 to 87mb) but a greatly reduced latency for all transactions. Order of magnitude, meaning big, like going from 100ms or more to only a few ms, and that is where my ears perked up. Reduced latency is what online twitch gaming is all about. Oddly enough I have the exact mobo chipset and add in nics as this user, and seem to be getting similar results.
Audio
One example relative to my case was a user who noted 17 percent cpu use simply viewing a youtube vid with onboard sound, going to a sb live card got him down to say 10 percent cpu, going to an audigy 2zs (a very old card by todays standards) got him down to 2 percent. I had a audigy 2 around here for some time but never tried it, popped it in today and it's working fine. Some glitches noted when watching vids or gaming seem to be greatly reduced, even though no sound cards are hardware acceleration anymore - all are cpu driven, apparently some are better than others.
As to Placement, here's the why and how;
Consulting the mobo manual revealed the block diagram of the chipset showing wich pcie lanes were where and how the pci lanes were laid out and who they connected to - the cpu or the northbridge chip (in the case of this intel system). Most everything onboard; sound, vid, net, is all going thru the northbridge. What I decided on was to place each major component on its own bus (pcie, pci, or straight to the cpu), as per the mobo manual.
The nic is a pcie server card with a pcie8x formfacter. The only free pcie slot was directly under the gpu but since the card's tiny figured there's no problem with it blocking cooling of the gpu. The gpu, on a pcie16x bus, has its own link directly to the cpu. So there's the nic sorted.
On the sound card, I noted that pci lane 1, the very bottom pci slot, was all alone on its way to the northbridge, sharing the bus with nothing else, bingo, there's the slot to use.The bottom slot also put if ar away from notorious noise makes like usb lanes and psu trash.
So far so good, only had to find a driver for the sound card, win7 had the driver for the nic.
The idea is to have every major component on its own bus, and that has more or less been achieved in this instance.
It's still old crap pc parts no one wants or uses today, but I'm wringing all the fps I can outta them.
Back in the day you could get a gaming nic;
https://www.newegg.com/killer-nic-m1/p/N82E16833342001
A (further) Word on Smooth Gameplay
It used to be easy to get smooth gameplay when all we had was one cpu core. Now the core counts are ever increasing while most older games, T1 and T2 included, are single threaded and at the mercy of the scheduler of any given os. A thread is that part of a program that gets executed by a core - ie math. A scheduler more or less is the part of the os that decides what thread gets run and when and it's trying to keep some cpus running over 3GHz busy.. This paradigm presents a serious problem in some cases, especially where the scheduler moves a single threaded game to any core not busy at the time time the thread's scheduled to run. That movement entails a lot of behind the scenes chicanery as the cache is flushed and filled with new contents on the current core, and the core the game thread just departed does likewise. All of that takes time, almost an eternity in the view of a cpu. Sure the game still runs on an smp sys, but oddities like audio glitches and erratic fps can be noted, expecially in the case of T2. Things would be smoother in gameland if a smp system kept threads to the same core as much as possible, and not just in gameland. Newer games are typically coded to ensure smp poses no problems and even increase performance of the game.
When NT came along it had a kernel that was smp aware and will make use of multiple cpus, but had a FIFO or first in first out scheduler. That means whatever the scheduler ordered the memory to load into cache was booted out by the contents of the next cache order, even if the former was more desirable - from a performance standpoint - than the latter. This was followed on by 2K wich had a LRU cache methodology, meaning the least recently used cache contents gets flushed - but only when a single core was present, in smp 2K was FIFO, so 2K's a more polished NT but with the same smp scheduler more or less. Then came XP, with a LRU algo running the cache in smp or up (uniprocessor) systems. But XP still would cache thrash in smp since the scheduler wasn't a per processor runqueue type, a per processor runqueue tries to keep the same thread and cache in the came core in an smp system. The per processor runqueue was fielded by M$ in Server2003, then Vista, and is present in all M$ os since far as I know. That said, things are better, but threads are still thrashed even in an per processor runqueue, just to a far lesser degree.
When all we had was 2 cores it still wasn't so bad with cache thrashing, as the malady was coined, and easily dismissed, but with more than 2 cores it becomes something that cannot be ignored visually, not only that, it can reduce performance.
So what's the solution?
I recently went from a 2 core game sys to one with 4, and at times the game would actually drop below 30fps, something that never happened with the same hardware (other than the cpu) in the old sys. I presumed correctly it was due cache thrashing, as employing a batch file that set the affinity to a single core for the game showed, now not only is there creamy smooth gameplay but the well known audio glitch when using the jets is eliminated.
See here for practical solutions;
https://www.tribesnext.com/forum/discussion/473/my-server-and-or-game-is-jittery#latest
related;
A Word on Priority
The previously mentioned bat file solution to the cache thrashing of T2 has an interesting switch in the string, see here;
del /s /q *.dso
start /affinity 1 /abovenormal Tribes2.exe -online
A Word on Tweaking Win10 and 11;
This thread got my attention when looking for lag inducers;
"Recently, a youtuber named 'Tech Yes City' did a comparison Video between Windows 10 vs Windows 11 and found out that W11 has more latency.
It's pretty interesting to see what he tested. He specifically compared TPM, Secure Boot on vs off and saw a 3ms reduction in Lag (mouse movement to photon delay), just by disabling these settings inside bios.
Also, he showed that disabling backround services and tune/debloat windows does make a big difference for Latency, no matter which windows version.
I'm happy to see someone finally testing these things, because it was in debate that these settings decreases lag."
The utility used to tweak 10 and 11 can be found here;
Back in the day we used something called XP Antispy to do much the same;
I eventually learned what services were safe to disable or set to manual and still have a working system, after much anguish, lol. A XP Services guide was handy for starters;
https://www.tweakhound.com/xp/xpservices.htm
And something for us Win7 users;
Use at your own risk!
This thread is a goldmine! I'm glad you are still updating it years later. Also, as someone who is currently playing T2 on Linux, I would recommend that as an alternative to W11. It works very well. Anyway, I hope you don't mind me including this thread in my next Tribes 2 Content Pack version, as it contains a lot of good info.
I am humbled you'd do so, please feel free to add it/edit it to suit.