Almost. Z is x and θ is y. Note how I paired the two x coordinates and the two y coordinates together in the If statement.

Yeah, I actually had a routine written for that which hijacked the 16/16 division routine, but deleted it in favor of the 8.8 division routine. However I realized that the 8.8 division routine doesn't work, so I'll try to recreate what I had before:

p_Inverse:
.db __InverseEnd-1-$
xor a
bit 7,h
push af
jr z,$+8
sub l
ld l,a
sbc a,a
sub h
ld h,a
xor a
ex de,hl
ld bc,16<<8
ld hl,1
call $0000 ;sub_Div+10
pop af
ret z
sub l
ld l,a
sbc a,a
sub h
ld h,a
ret
__InverseEnd:
.db rp_Ans,12


Yes, an infinite loop. The check in a For() loop consists of checking if the variable's value is greater than the upper bound. However, because a 16-bit number can never be greater than 65535, the condition will never be met and the loop will never end.

EDIT: If you need a loop with those bounds, use this instead. It's smaller, faster, and stronger too! (Well, maybe not stronger)

0
While 1
  →Q

  ;Put your code here

End!If Q+1


I don't know of any speed-optimized function specific to taking the inverse. But that definitely doesn't mean one doesn't exist. However, you could easily implement it if you added 8.8 fixed point division:


p_Inverse:
   .db 7
   ex   de,hl
   ld   hl,$100
   call   $0000      ;sub_88Div
   .db rp_Ans,2


p_88Div:
   .db __88DivEnd-1-$
   ld   a,h
   xor   d
   push   af
   bit   7,h
   jr   z,$+8
   xor   a
   sub   l
   ld   l,a
   sbc   a,a
   sub   h
   ld   h,a
   bit   7,d
   jr   z,$+8
   xor   a
   sub   e
   ld   e,a
   sbc   a,a
   sub   d
   ld   d,a
   ld   b,24
   call   $0000      ;sub_Div+2
   pop   af
   add   a,a
   ret   nc
   xor   a
   sub   l
   ld   l,a
   sbc   a,a
   sub   h
   ld   h,a
   ret
__88DivEnd:
   .db   rp_Ans,12



EDIT: Just kidding, that hijacking of the 16/16 division routine to make an 8.8 division routine doesn't work. But it's definitely possible to hijack the 16/16 division routine at least for an 8.8 inverse.

Here Darl181, I wrote this just for you! (Although other people can feel free to use it too!)

http://ourl.ca/4129/212961

I don't quite understand why it would be hard to make passes optional. Could you make normal parsing the 4-pass system that moves data to the end? But if this option is turned off, start parsing with a pass outside the normal 4-pass system that acts like the first two passes combined and then resumes with/jumps to the final two passes as usual? This "fifth" pass would probably share a lot of redundant code with the first two passes, but you're not exactly tight on space in the application, are you?

The only case when this new 4-level grayscale routine should have noticeable problems is when it's alone in a loop with no other delay, simply because it's faster than the old routine. In most real situations that it would be used in, there would probably be much larger delay between display calls, like rendering a frame, in which case you want the routine to be as fast as possible.

I would leave the 3-level grayscale routine in column-major but use the 4-level grayscale routine in row-major order, because they are both faster than their alternatives. Although this will allow for 4-level grayscale to draw from arbitrary buffers and not allow for it in 3-level grayscale, I wouldn't worry too much about the incongruity. Being able to call 4-level grayscale with arbitrary buffer arguments would be quite awesome.