For quicker access to the console open your Doom 3 shortcut properties and add:
+set com_allowConsole 1, e.g. "C:\Doom 3\doom3.exe" + set com_allowConsole 1.
This allows you to access the console by pressing the Tilde ‘~’ key (default is Ctrl+Alt+Tilde).
Benchmarking/Recording Demos
Doom 3 features passable benchmarking features, although it’s restrictive enough as to their relevance, or as John Carmack put it recently – “Timedemo doesn't do any game logic. Demos are always recorded at exactly 30Hz.” That and the frame rate is by default limited to 60Hz, as such benchmarking will always yield better performance than you will actually get in the game so bear that in mind.
Regardless of all this, benchmarking is still the best way to tell how effective your new customs settings are performance-wise, e.g. the results beneath indicate I’ve been a bit over-optimistic as regards using higher quality graphics settings.
Benchmarking is carried out by entering commands into the console, the use of which was discussed in the previous section. Relevant commands are as follows:
recordDemo “x”. x specifies the name of the demo you wish to record, e.g. recordDemo mybench will begin recording (At 30Hz per second) a demo named mybench. It goes without saying that for a benchmarking demo that you should try to record a section with a good deal of enemies to fight or lots of lighting.
stopRecording. If you were expecting this command to do more than the obvious then you were wrong, it just ceases recording the demo you had initiated with recordDemo “x”.
playDemo “x”. x specifies the name of the demo you wish to playback, e.g. playDemo mybench will load the mybench demo.
playdemo stop. This command ceases playback of the demo loaded with playDemo “x”.
timeDemo “x”. This is used to benchmark the x demo, e.g. timeDemo mybench. The results are displayed after the demo is run, with the average frame rate being determined by the number of frames in the demo divided by the seconds it took to render them. It is worth noting that a timedemo should be performed twice in order to get accurate results, on the initial run data will most likely need to be loaded – which will be cached for subsequent runs.
timeDemoQuit “x”. This operates exactly as timeDemo “x” previously, albeit instead of displaying results when finished the game quits. Not too sure what the point of this would be.
