D A I K A T A N A T W E A K G U I D E
Daikatana, like any QuakeX-engined game, is extremely open to graphical and performance tweaking through the use of CVARS. In this guide we take a look at some ways to eke out another frame-per-second or two of performance, or how to glean more flash, dazzle, and pizazz from Daikatana's visuals.
This article is specifically aimed at explaining as many as possible of the CVARS contained in these two config files, which have been modified for use with Daikatana:
Best Visual Quality | Fastest Perfomance
To use the config files, download them and extract them to your daikatana/data directory. Load Daikatana, bring down the console, and type exec quality.cfg or exec performance.cfg and then hit Enter. The configs automatically restart the video subsystem, so don't freak out when your monitor blanks and clicks.
Since side-by-side screenshot comparisons of stuff that doesn't show up on screen isn't exactly possible, all the CVARS in these two .cfg files have been re-categorized into "Non-Visual Tweaks," "Visual Tweaks," and "Limbo Tweaks." For example, under this categorization an undeniably graphical tweak like cl_maxfps is considered non-visual because a screenshot can't show the difference between 35fps and 85fps. The "Limbo Tweaks" contains settings for which a visual difference couldn't be easily determined but which should be noticeable and by all rights should affect performance as well.
Please direct any errors, inaccuracies, inconsistencies, or questions to Wadmaasi.
Many props go to:
- Brett "3 Fingers" Jacobs for creating the original tweaked-out Quake2 .cfg files on which these are based.
For some unknown reason, the playing back of multiplayer demos in timedemo mode is broken in DK, but you can play singleplayer demos in timedemo. Here is a benchmarking demo for use in gauging how much difference these settings make on your particular system. If you're interested in recreating what is in the demo, skill was set at 3 (skill 3) which technically is one step up from Shogun and may or may not be any different than Shogun, the map is e1m4b (map e1m4b), and cheats were used like crazy (cheats 1). For accuracy in testing, make sure you turn vsync off for your videocard before running timedemos. Always type vid_restart into the console after manually making any of the changes in this guide.
Instructions for playing back the demo:
- Extract the test2.dem to daikatana/data/maps.
- Load DK and bring down the console.
- Type timedemo 1 and hit Enter.
- Type map test2.dem and hit Enter.
- Watch the demo.
- Bring down the console and check your average frames-per-second.
- Make changes, and repeat.
set cl_predict "1"
This turns on client-side predicting of pretty much everything (projectile movement, whether or not that C4 around the corner is there to be picked up, player movement, etc) when playing a multiplayer game. For modemers, this should always be on. If you've got a ridiculously low latency to the server (ie a ping of 50 or less) you could turn it off, but any world-state status gains wouldn't probably be noticeable, so leaving it on won't hurt anything.
set s_mixahead ".14"
I have no idea what this does, really. *heh* Something to do with sound, but exactly how it affects sound...?
Again, I can't find any information on what this variable actually does. Both .cfg files set it to on, however, so it must not hinder performance.
This controls how many frames-per-second the game will allow to be rendered. For visual quality, you want this set high; if you have vsync on set it to your refresh rate, if you have vsync off set it to something higher than you'll likely achieve like 100. However, for netplay, if you're on a modem you will want to cut this down drastically due to the way the rendering and networking are tied together in the Quake2 engine. For each frame that your computer and videocard render, your client sends 1 packet to the server. If you're on a DSL, cable, or ISDN connection with good bandwidth, this isn't really an issue. But if you're on a 56k modem (even one connecting at 50,333bps), trying to pump 85 packets per second to the server is going to overload your connection right quick and cause lots of warping, stuttering, and freezing in place for seconds on end as you and the server try and sync up. As such, you'll want to artificially cap this during netplay. A setting of 35 on a solid 56k (visit Optimizing.Net for an excellent guide to gaming-oriented configuration of dial-up networking for Win9x, WinME, WinNT4, and Win2k) that pings servers in the 200-350 range has been found to provide acceptable connection smoothness and stability.
Disables (or enables) the joystick. If you're not using one, set to 0 in order to prevent your system from polling the gameport during play and recoup a few CPU cycles per second.
Tells the game to initialize the mouse for mouselook. If you don't use mouselook (freak!), you can set this to 0 and gain about the same amount of benefit as you would from disabling joystick support.
Set to 1, this causes the game to average movements of the mouse over time, resulting in a smoother mouse movement at the expense of adding some latency between the time you move your hand and the time the movement registers on-screen. Really, though, this is so marginal that you won't notice it. If you think you do, though, you can set this to 0 and get a faster (and jumpier) mouselook.