Well - from what I've seen most people seem to be using multicore processors but I wonder how many have heard of the infamous "mat_queue_mode" variable in TF2 (and all newer Source-based games).
Usually TF2 only does particle calculations on the second (or any other ^^) core, so there's really not much improvement over single-core machines although that makes the performance more CPU-dependent than in many other games.
However, by setting:
mat_queue_mode "2"
in your config file (create an autoexec.cfg text file in your steamapps -> your@account -> team fortress 2 -> tf -> cfg folder if you haven't one already) you can force TF2 to load some more stuff onto your other cores. Keep in mind that this feature is VERY unstable and may cause various problems and crashes.
To avoid them you can do some further tweaks and testing with the following variables:
host_thread_mode "1"
This is only useful if you're both the host and client on the same machine but there's no reason to NOT use it and for some strange reason people have reported mat_queue_mode "2" to be working better with this turned on.
These are the DEFAULT settings for the variables unless defined otherwise. As you can see only the particles are loaded into the second core. You should try using mat_queue_mode "2" with this default config first to check if it's stable at all. Then you can enable further features.
cl_threaded_bone_setup "0"
cl_interp_threadmodeticks "0"
cl_threaded_client_leaf_system "0"
r_threaded_client_shadow_manager "0"
r_threaded_particles "1"
r_threaded_renderables "0"
r_queued_decals "0"
r_queued_post_processing "0"
The next two variables are CRUCIAL for making the whole "experiment" work. These AREN'T the default values for them - in fact they turn them OFF. HL2 automatically enables them if it thinks that your computer can handle them with mat_queue_mode "2" but in most cases it shouldn't since THEY are responsible for most crashes. Truth be told I couldn't get mat_queue_mode "2" to run in a stable manner with them set to anything other than "-1" but your mileage might vary...
mp_usehwmmodels "-1"
mp_usehwmvcds "-1"
Now comes the fun part. I boldly enabled most of the features in my config and while some people reported an FPS increase of perhaps 20-30 or in some cases even an FPS DROP, I got an FPS increase of, I don't know almost a 100 (!) FPS on my overclocked Core2Duo E6600... 0_o
The problem here is that I've been getting ~300 FPS in simpler, closed areas, which is the most the Source Engine can handle but of course my monitor is running at 75 Hz and hence can show only 75 FPS and that lead to some INCREDIBLE choppiness and screen tearing (yes, kids - that's why you should ALWAYS have VSYNC enabled unless your average FPS are close to your monitor refresh rate or you're running some benchmarks). The solution for this WOULD have been enabling VSYNC, which I have always enabled to limit my FPS to the refresh rate anyway since disabling it is friggin' moronic and usually only means that you don't know what it actually does BUT on my setup mat_queue_mode "2" kinda b0rked it - the FPS were jumping wildly between 75 and like 300 and this caused an incredible jitter... Turning VSYNC off wasn't a solution either, because then I had the usual share of problems, too, as I outlined above...
Then it dawned on me that there's one good ol'e variable I completely forgot about:
fps_max 75 (or simply your refresh rate in 3D mode and the given resolution)
This allowed me to limits the FPS by hand to a handy-dandy 75 which is the most my monitor can display anyway and it even made VSYNC work correctly because the FPS didn't get the chance to "jump around"!
Now my FPS are stuck at 75 no matter what even on my modest over 1-year-old rig and they used to decrease to around 50-60, perhaps even 40, in larger areas and heavy fights (I'm running maximum settings for everything, reflections FSAA etc.)... This is friggin' sweet!
Now - as a final note I'll post my current config in autoexec.cfg - you might need to tweak it to your needs, it might not work on your machine at all or dramatically DECREASE performance - also, HL2 can crash frequently, so YOU HAVE BEEN WARNED.
However, it might actually work as smoothly as in my case and then you're in for one awesome gaming experience, especially if you were forced to use lower quality settings or had low FPS until now (remember that this requires AT LEAST a dual-core machine!)
Code:
//Multithread test
mat_queue_mode "2"
host_thread_mode "1"
cl_threaded_bone_setup "1"
cl_interp_threadmodeticks "1"
cl_threaded_client_leaf_system "1"
r_threaded_client_shadow_manager "1"
r_threaded_particles "1"
r_threaded_renderables "1"
r_queued_decals "1"
r_queued_post_processing "0"
mp_usehwmmodels "-1"
mp_usehwmvcds "-1"
fps_max 75
P.S. You can enable/disable VSYNC on startup without going through the annoying GUI with
mat_vsync "1"
Again - unless it causes some major problems you should ALWAYS have it enabled...
Login
FAQ
Search
I don't think that it needs so much memory the other times. I think it's about 400-500MB 
