Why 256 values?

The main reason as I see it is that you won't have to worry about rounding large angles down so that they lie in a 0-360 degree range. All you'll have to do is AND the angle with 255 and look up the result in the table.

The main reason as I see it is that you won't have to worry about rounding large angles down so that they lie in a 0-360 degree range. All you'll have to do is AND the angle with 255 and look up the result in the table.

Reading the COS value from the SIN table is also fairly easy:

ADD r0, r0, #64 << 24
MOV r0, r0, LSR#24
LDR r0, [r1, r0, LSL#2]

ADD r0, r0, #64 << 24
MOV r0, r0, LSR#24
LDR r0, [r1, r0, LSL#2]

For the benefit of anybody else using this technique, you can avoid the ADD instruction by replicating the first 90 degrees worth of table at the table end, so you have 450 degrees of data, and then adjusting the value of r1.

f1616_sin ; r0=in,r0=out
	; since sin x=cos (x-90)...
	SUB R0,R0,#90*65536
f1616_cos ; R0=angle, returns value
	CMP R0,#0
	RSBLT R0,R0,#0 ; Make positive
f1616_cos_loop
	CMP R0,#360*65536
	SUBGE R0,R0,#360*65536
	BGT f1616_cos_loop
	MOV R1,R0,LSR #12 ; Get location in table
	SUB R0,R0,R1,LSL #12 ; Get interpolation factor
	ADD R2,R1,#1 ; Location of 2nd value 
	; Work out quadrant
	CMP R1,#180*16
	RSBGE R1,R1,#360*16 ; Reflect if >180
	RSBGE R2,R2,#360*16
	CMP R1,#90*16
	CMPGE R2,#90*16
	RSBGE R1,R1,#180*16 ; Reflect again
	RSBGE R2,R2,#180*16
	LDR R3,f1616_costabptr
	LDR R1,[R3,R1,LSL #2]
	LDR R2,[R3,R2,LSL #2]
	MUL R2,R0,R2
	RSB R0,R0,#4096
	MLA R1,R0,R1,R2
	RSBGE R1,R1,#0 ; Negate answer if needed
	MOV R0,R1,ASR #12 ; Back to 16.16
	MOV PC,R14

One should insert other useful instructions between the MOV and LDR if possible, since memory accesses are slower if the regs are adjusted in preceeding ops.

ADD r0, r0, #64 << 24
MOV r0, r0, LSR#24
LDR r0, [r1, r0, LSL#2]

Ppht. too slow.
One should insert other useful instructions between the MOV and LDR if possible, since memory accesses are slower if the regs are adjusted in preceeding ops.

One should insert other useful instructions between the MOV and LDR if possible, since memory accesses are slower if the regs are adjusted in preceeding ops.

Do you mean that there's an extra cycle of result latency because r0 is shifted by an immediate constant in the LDR instruction? True. LDRs aren't delayed by any old write to their source registers in the preceding instruction, it's just for shifted operands (and just on XScale).

You don't want to go using the result of the LDR within the next 2 cycles, however. (XScale, 1 cycle on SA)... leave it as late as possible, in fact; the data may not be cached!

<sarcastic>Aha, so the whole reason why my game is too slow is because I'm wasting cycles.

Wow! I was thinking it's that silly "C" stuff, with all its bloat-code around entry and exit procedures. Thanks for the tip!</sarcastic>

I can move it if you wish...

Jeffry and Adrian are correct - powers of 2 have binary advantages, but to add to that : perhaps you should be asking yourself "why 360?"
256 also has the property of fitting in a byte, which is often useful, and there is of course the ARM constant issue. But if you need more accuracy, use more bits!
Why did you start using trig. functions in the first place - could you give us some idea of what sort of map you really want?
I think you want large caverns, but are there any other desires?

He found that LDRs were affected by their addressing operands changing. This is different to what Acorn stated. Can't seem to access the website now, so I can't check.

Does moving it beyond 2 instructions change anything? I understood that if it wasn't cached the processor would pause anyway.

I can move it if you wish...

Did you mean to post this in the '2's complement' thread?

Cheers,
Rich.

I can move it if you wish...

Did you mean to post this in the '2's complement' thread?

No, the Programming section that you mentioned in your previous post.