@NovaSquirrel I dunno what your formulas are, but presumably you could do it with just a starting set of values, and then compute subsequent lines using finite differences?
I'm guessing there's a reciprocal term that makes them not just linear, but you might be able to approximate that with a quadratic that does work as differences?
Also there might be an 8-fold symmetry here that you can exploit to transform 1/8 of the table entries into the others?
@rainwarrior I'm unfamiliar with finite differences, but I feel like even just building the table in RAM would have massive space savings, since M7A=M7D, and M7B=-M7C. So that's 10 bytes/scanline/angle down to 4.
It's mostly trig function(angle)*scale*(1/y), and if I could multiply quickly that could be reduced to just one multiplication per scanline and two tables. I might try symmetry.
@NovaSquirrel Finite differences is just an efficient way of calculating successive results of a polynomial.
Like if you think of a parabolic curve of a projectile (i.e. quadratic polynomial) versus euler integration, that's a finite difference technique (order 2).
Basically for each step you do one add for each term in the polynomial. If you're function isn't too "spiky" you can probably approximate it with a low-order polynomial this way.
@NovaSquirrel So instead of storing a set of values per scanline, you find a best fit quadratic or cubic curve for each angle and store just the first 2 or 3 scanlines* to define the curve, and the rest is computed from differences.
(* really you'd store the differences rather than the 2nd, 3rd, etc. scanlines but it's an equivalent amount of data either way.)
@NovaSquirrel Though... after saying it I realize that "find a best fit curve" is a whole research topic of its own if you haven't done this kind of thing before.
Oh hey, rotation! I'm using 32 angles right now and so I have two entire banks dedicated to HDMA tables because currently each angle is a whole 1772 bytes. Worth it for good-looking turning though!