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 ...