Optimize.Txt This text file is a guide for use by QB/QBASIC programmers to help optimize the program code for greater efficiency. If you have any questions, contact VirtuaSoft at gump@gnt.net. Address to Danny. (Note: This is not for the beginning programmer. A strong background in QB/QBASIC programming is highly recommended.) 1. Math Calculations a. Factoring b. Integers c. \ vs. / d. Premade tables 1. Math Calculations a. Factoring If possible, multi-stepped math should be factored completely so that the computer has to take the least amount of steps to calculate the end result. One texture-mapping library I was writing in QB required 43 steps to calculate a pixel before placing it on the screen. This made the program very slow, but by factoring the entire equation, I was able to decrease the steps to 24, thus allowing the program to roughly double in speed (although it still is way too slow for real-time polygons). ex. Before: POKE perx2*x1&*pery2\dx\dy+perx2*x4&*pery\dx\dy+perx*... x2&*pery2\dx\dy+perx*x3&*pery\dx\dy+320*pery2*... y1&*perx2\dx\dy+320*pery2*y2&*perx\dx\dy+320*... pery*y4&*perx2\dx\dy+320*pery*y3&*perx\dx\dy, color After: POKE ((x1&*pery2+x4&*pery)*perx2+(x2&*pery2+x3&*pery)*... ...perx)\dx\dy+320*(((y1&*perx2+y2&*perx)*pery2+... ...(y4&*perx2+y3&*perx)*pery)\dx\dy), color Don't feel that you need to understand the equations above; they are merely serve to show the length decreased by factoring. So you can see how the factoring greatly shortens not only the calculation time, but it also shortens the code, thus being a win-win situation for programmers. I also discovered that by factoring a set of calculations, the numbers are more accurate since values aren't rounded. So that's three good points to it. b. Integers QB and QBASIC have four types of variables: integers, long- integers, single-precision decimals, and double-precision decimals. Since computers are made to calculate numbers as binary integers, it would only seem logical that integers in BASIC would be the easier to use (for the computer) than floating-point (decimal) numbers. Decimals aren't directly held in memory, but it takes many steps to set up a decimal to be stored in memory. These steps can greatly slow a program by requiring it to do more calculations. Since the binary in memory is meant for only integers (non-negative powers of two), decimals are actually stored as fractions (negative powers of two). To calculate this, much time is consumed because these values do not actually exist in memory but are synthesized by the BASIC software. Using integers when possible will eliminate this need for unnecessary calculations, thus increasing the speed of a c. \ vs. / Every who programs BASIC knows what the / means, but unless you have been programming for quite some time, you may not have ever used the \. The \ is the integer divide (as opposed to / which is the floating-point divide). As mentioned in the last section, integers should always be used when possible. The integer divide falls right into that category. But why use \ when dividing values like 2 into 8? Well, 8/2=4, right? Those are all integers. You know that; I know that. But that doesn't matter because we aren't the ones processing this while running the program. For the computer 8/2 doesn't mean 8/2 even though those are integers, but it sees 8.0000000/2.0000000. The integers were just converted to floating-point numbers for the division, then reverted back to integers afterward. How inefficient can you get? Let's try another one: 9 divided by 4. In Math class, this would be 9/4=2.25. On the computer, this would be 9.0000000/ 4.0000000=2.2500000 or 9\4=2. As you can see, integer divide doesn't give any decimal answer, but it truncates or INTs the answer, so be careful when using it because you will sometimes want the most precise answer over a 1200% increase in the program's speed. It's your choice. d. Premade Tables Sometimes you may want to use some of BASIC's functions that give decimal answers like COS or SIN. But why use decimals when you can use integers over these very slow floating-point calculations? The solution would be to use a table of integer values. But wouldn't this be less accurate? No, it would not be to any noticeable degree. By now you are probably wondering how to use integers for calculations that require decimals. The solution would be to make your table have values that are 100x, 1000x, or 10000x what the function would normally return for a certain inputted value. Then simply integer divide the finalized calculation by that 100, 1000, or 10000. ex. table: cosine(0)=100:cosine(10)=98 cosine(20)=94:cosine(30)=87 cosine(40)=77:cosine(50)=64 cosine(60)=50:cosine(70)=34 cosine(80)=17:cosine(90)=0 start: ? 500*cosine(0) \100 500 ? 500*COS(0) 500 ? 500*sine(45) \100 353 ? 500*SIN(45) 353.5533906 Voila! There you have it. As you can see, there is no huge deviation between the INTEGER value and the decimal value, so this can be used for any math that outputs integers, like rotating graphics. ... This concludes the lesson ...