As a side note, when it has been below the time limit you should probably use the EDIT button to not double-post, else you can lose the game.

Well I wanted to post the source for a routine I had just made, but the option to attach files seems to have vanished...

It's because of the server move, I think.

Cool, I now have access to the forums again.

Anyways, the routines I had were a pair of deadly accurate sine and cosine routines. And by deadly accurate I mean percent errors in the hundredths or thousandths of a percent. Whereas the built-in routines accept integer inputs and give signed 8-bit integer outputs, these routines accept 8.8 fixed point inputs and give signed 8.8 fixed point outputs. That means it accepts inputs with 256 times the precision, and gives outputs with 256 times the precision as well!


The first file (TRIGLIB.8xp) is the library you probably want to use in most situations, as it's slower than the second library but over 300 bytes smaller. This is because, whereas the first library uses a 128-byte LUT for one quarter of the period and makes use of the symmetry of the sine wave to do extra calculations for values anywhere in the period, the second uses a 512-byte LUT for the full period.


EDIT: Oh right, I forgot to say: use sub(SIN,value) and sub(COS,value) to use them. And to properly insert a library like this into your program, put a line saying prgmTRIGLIB in the subroutine section of your code.

Well obviously they're not going to be as fast as the built-in sine and cosine routines, as not only are those written in pure, optimized assembly, but they don't have to be nearly as accurate. Timing the routines at 6MHz gave these results:

• The built-in sine routine calculates the sines of 1-65535 in about 4.4. seconds (let's call this 100% speed)
• My size-optimized sine routine calculates the sines of 1-65535 in about 23.1 seconds (19% speed)
• My speed-optimized sine routine calculates the sines of 1-65535 in about 17.7 seconds (25% speed)

19% speed may sound a bit slow, but that's still almost 3,000 calculations per second. So these routines are about 4 (speed-optimized routine) or 5 (size optimized routine) times slower than the built-in routines. My routines are also 12 (size-optimized routine) or 22 (speed-optimized routine) times the size of the built-in routines (378 or 695 vs. 31 bytes). But you get 256 times the accuracy, so depending upon what you need, it could be worth it.

making accurate polygons

Although if you wanted to get the highest speed you would prerender a sin table into somewhere in memory to get high accuracy and high speed ^^

Oh whoops i misread your post :O It already is a LUT! *party*

EDIT: Wow that is really clever with the blending!

Ah I see. So I take it that the regular routines cannot achieve 3D and raycasting, or is it just too innacurate to achieve decent ones?