How does Doom determine its cosine lookup table from an existing sine lookup table?

Viewed 225

I'm struggling to understand how Chocolate Doom assigns its cosine table. The comments explain that it does a PI/2 shift on the sine table in order to calculate the cosine table, but I don't understand how it's done using C.

Here is Chocolate Doom's original source code in tables.h and tables.c

#define FINEANGLES 8192
const fixed_t finesine[10240] =
{
    25,75,125,175,226,276,326,376,
    ...
}
const fixed_t *finecosine = &finesine[FINEANGLES/4];

This is what I'm trying to achieve in Kotlin

val fineSine: Array<Fixed_t> = arrayOf(25,75,125,175,226,276,326,376, ...)
val fineCosine: Array<Fixed_t> = arrayOf() // This is where I'm stuck
2 Answers

A full circle is 2pi radians. So to offset by pi/2 you need to go a quarter of the way around. So if you have FINEANGLES values in the circle, you can offset by FINEANGLES/4.

But in order to have access to FINEANGLES values in finecosine finesine needs to have at least FINEANGLES + FINEANGLES/4 values (assuming there isn't logic to wrap around).

A simplified example:

#define FINEANGLES 4
float finesine[] = {0, 1, 0, -1, 0};
float *finecosine = &finesine[FINEANGLES/4];  // {1, 0, -1, 0}

A follow-up question to the doom finesine table. As I undertstand the table captures the full 360degrees for sine (and cosine - thats thats why it has 10240 elements in difference to the 8192 elements).

Now my questions is. Wouldn't it be more efficient to only capture the 1st quadrant (90 degrees) in a lookup table and cosequently adjust the sign (+/-) and shift the lookup. For example:

sin(37 deg) = -sin(217 deg) = -cos(127 deg) = cos(307 deg) = (+/-)0.60181502315

So you could either just have 1/4th of the original lookup table size or maybe higher precission with an equally long LUT.

Computationally you add 4 comparions (in which quadrant is the angle), a shift (substraction) and a mult by -1 vs a div by 4 for the cosine.

Related