This site is no longer active and is available for archival purposes only. Registration and login is disabled.

tips to speed up quake


tips to speed up quake

Postby rcoffey » Jan 25, 2001 @ 12:07pm

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
rcoffey
 


Re: tips to speed up quake

Postby Mark (KILzt) » Jan 25, 2001 @ 12:59pm

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.
Mark (KILzt)
 


Re: tips to speed up quake

Postby 999 » Jan 25, 2001 @ 3:15pm

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
Image
999
pm Member
 
Posts: 1227
Joined: Jan 24, 2001 @ 11:48pm


Re: tips to speed up quake

Postby Mark Rejhon » Jan 25, 2001 @ 5:35pm

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 :)
Mark Rejhon
 


Return to Pocket Quake 1 and 2


Sort


Forum Description

Discuss Pocket Quake 1 and 2 by Dan East

Moderators:

Dan East, sponge, James S

Forum permissions

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

cron