tips to speed up quake

[rcoffey]

turning off the weapon helps a bit<br><br>r_drawviewmodel "0"<br><br>i also set d_mipscale to 40, which is the lowest setting, helps a bit more with the framerate.<br><br>any other suggestions would be helpful.<br><br><br>I was also curious what type of speed improvement is expected through optimizations?<br><br>thanks in advance.<br><br>Robert

[Mark (KILzt)]

There should be a way of turning dynamic lighting off; in OpenGL it's gl_flashblend or something. I remember a line to do that in software mode as well.<br><br>Generally none of the optimisations I've seen so far are worth the use because the increase they give is next to none. Better to just free up 20mb of Ram and O/C the iPAQ all the way up, need more ram for stability at higher clock rates - don't know why.<br><br>Nothing really makes any impact on speed with such a small display anyway; it’s ultimately up to Dan to improve the internals. Although I feel it could be a bit more difficult then he current expects.

[999]

Right now, I've done as much as I can in the autoexec to lower the rendering load.  <br><br>You'll notice a difference in complex areas with and without the settings.<br><br>Unfortunately, the Flashbend and other lighting tricks can't be disabled by the user in Quake, but only GLQuake. Dan has manually removed the sky and other elements to see if any speed was gained, however it didn't appear to have any positive results.<br><br>Right now, there is a bottleneck in the math, I'm under the impression it's getting emulated somewhere because the iPAQ's math is different.  NO matter the screen size or resolution, that bottleneck is still going to hamper the performance.<br><br>Last I spoke to Dan he was working on optimizations, one specifically which could take some time to lay down.  It involves the math end of Quake, and from what I have been told, is not only tricky, but very tedious. Despite that, the results he's gotten from changing things around appear to be very very promising, up to a 5x increase in performance.<br><br>Cross your fingers, there are thousands of lines of code he must examine and alter.<br><br>Last modification: 999 - 01/25/01 at 12:15:24

[Mark Rejhon]

I guess StrongARM has fast floating point math, but supports only a subset of mathematical functions that are available on DOS platforms, I presume!<br><br>Like trigonometry.. I remember in the old days, some programmers often used lookup tables to speed up trigonometry at the cost of some granularity.   That probably wouldn't work too well with a BSP-like engine found in Quake...<br><br>I assume that if there is high speed floating point add/subtract/multiply/divide/etc, but missing native trigionometry functions in the StrongARM CPU (I'm not familiar with what the StrongARM/XScale architecture supports), that's going to be a bit tedious to figure out the best way to emulate trigonometry...<br><br>Let's hope a StrongARM assembly language programmer does some wonders to PocketQuake