by Dan East » Apr 19, 2001 @ 9:53pm
The optimal framerate would be very hard to predict. I definitely feel 15 fps would be achievable on the iPaq (240x180 resolution). The problem is that their aren't many isolated optimizations left that can be performed. In other words, each optimization requires more work than the previous and involves modifying more routines, just to get a small improvement.<br><br>There are basically 4 ways to optimize something like Quake:<br>1: Search for, and rewrite, any poorly written, inefficient C code. This is more of a style issue.<br><br>2: Look at the algorithms used (in this case they are primarily 3D) to see if there are shortcuts that may be taken, or different mathematical formulas that may be used that will produce the same result with less effort. <br><br>3: Sacrifice quality or what is rendered so less work is done.<br><br>4: Replace mathematical operations that the target hardware performs poorly (or does not perform natively) with more efficient alternatives.<br><br>Quake was originally written when the existing PCs were very weak, so they tried to squeeze out all the performance they could. Thus items 1 or 2 would not provide much improvement. id Software has pretty efficient code - at least I've not come across any blatant, obviously terrible code. Number 3 isn't an option for several reasons. That leaves number 4. Quake extensively uses a technique of storing numerical values called Floating Point. Internally the number is represented similar to scientific notation, where you have a mantissa portion containing the actual value, and an exponential part which scales the mantissa value. Now, unless the device's hardware is specifically designed to process floating point math (specifically, contains a Math Coprocessor), then it will perform terribly at floating point operations. That is because it takes many (over a dozen) individual integer mathematical operations to multiply two floating point values. That is called Floating Point Emulation, which is when floating point math is done via the software. Some processors (MIPS) are particularly bad at floating point math. This is either because the processor lacks integer operations useful in floating point emulation (thus requiring even more steps), or because the Floating Point Emulation routines built into the compiler are inefficient or poorly written.<br><br>So, what we have is software (Quake) which relies a great deal on a type of math not supported by any of the Pocket PC hardware. So if we can replace the floating point math with an integer-based type of float math (Fixed Point math, or Fixed Point Integer math), then we will speed up those operations at least 10 fold. The problem is that floating point math has HUGE range and precision. It can store a value in the range from 3.4E38 to 3.4E-38. It's precision is similarly minute. The trick is to profile the range of a particular floating point variable in Quake to find the max, min and smallest precision it holds during gameplay. Based on that it may be able to be converted to fixed point math, which has a much more limited range and precision (in fact, the more range it has, the less precision, and vice versa. Thus the programmer must determine exactly how much of each it needs to handle the ranges it will encounter in the game). It is very tedious work converting floating point to fixed point, but that is how each version of PQ has been faster than the last. That is really the only available method of increasing the performance of PQ. If a Pocket PC were made with a floating point processor (which Intel told me will not happen in at least the next year), then it would run PQ very fast, even if the CPU speed were only 133 mhz or so. Pentium processors have onboard math coprocessors, which is one of the reasons I can run Quake II at 1024x768 on my 300 mhz laptop faster than my 200 mhz iPaq can run Quake I at a crappy 240x180.<br><br>Dan East
Optimal performace.
