3D math using Suzy

[+karri]

Obviously using $4000 is a great choice for unit vectors 1.0.

 

Another thing is that there is some "magic rotations that will not cause cumulative errors.

16-bits   0x4000 = 16384
Magic Angles        Angular Error Limit = 0.005000 %

  COS     SIN    ISINE  ANGLE(deg)  %Error(deg/deg)  %Magnitude Error
 16382   255.992   256   0.89525642   0.0030521   -0.0000007
 16380   362.017   362   1.26609665   0.0045790   +0.0000022
 16375   542.983   543   1.89919328   0.0030537   -0.0000034
 16354   991.030   991   3.46780721   0.0030074   +0.0000110
 16350  1054.967  1055   3.69183785   0.0031041   -0.0000129
 16334  1279.023  1279   4.47737570   0.0018070   +0.0000110
 16322  1423.999  1424   4.98609928   0.0000989   -0.0000007
 16319  1457.976  1458   5.10538374   0.0016273   -0.0000129
 16305  1606.994  1607   5.62880539   0.0003496   -0.0000034
 16301  1647.075  1647   5.76966484   0.0045495   +0.0000458

Is there any other considerations to think about when doing 3D math with Suzy?

 

 

 

[42bs]

I think: Avoid Suzy as much as possible. AFAIK one can use delta approach also for rotation but you have to  correct the error from time to time.

 

[VladR]

On ‎12‎/‎9‎/‎2019 at 1:40 PM, karri said:

Obviously using $4000 is a great choice for unit vectors 1.0.

 

Another thing is that there is some "magic rotations that will not cause cumulative errors.

16-bits   0x4000 = 16384
Magic Angles        Angular Error Limit = 0.005000 %

  COS     SIN    ISINE  ANGLE(deg)  %Error(deg/deg)  %Magnitude Error
 16382   255.992   256   0.89525642   0.0030521   -0.0000007
 16380   362.017   362   1.26609665   0.0045790   +0.0000022
 16375   542.983   543   1.89919328   0.0030537   -0.0000034
 16354   991.030   991   3.46780721   0.0030074   +0.0000110
 16350  1054.967  1055   3.69183785   0.0031041   -0.0000129
 16334  1279.023  1279   4.47737570   0.0018070   +0.0000110
 16322  1423.999  1424   4.98609928   0.0000989   -0.0000007
 16319  1457.976  1458   5.10538374   0.0016273   -0.0000129
 16305  1606.994  1607   5.62880539   0.0003496   -0.0000034
 16301  1647.075  1647   5.76966484   0.0045495   +0.0000458

Is there any other considerations to think about when doing 3D math with Suzy?

 

 

 

Please, just resist and say no to this approach. I know that you have a great debugging set-up with real Lynx, but still - this approach will drive you nuts trying to reproduce a very occasional bug. That time is better spent putting more features in or watching Northern Lights or dipping in the lake

 

Just got for LookUp Tables or compute the thing each frame brute-force.

 

And if you can't resist, at least spend half day in Excel and create these huge 10,000 line long tables that will somewhat "emulate" the loss of precision. At least this way you'll know exactly how soon you can expect the error to become significant in your particular scenario.

[+karri]

51 minutes ago, VladR said:

Please, just resist and say no to this approach. I know that you have a great debugging set-up with real Lynx, but still - this approach will drive you nuts trying to reproduce a very occasional bug. That time is better spent putting more features in or watching Northern Lights or dipping in the lake

 

Just got for LookUp Tables or compute the thing each frame brute-force.

 

And if you can't resist, at least spend half day in Excel and create these huge 10,000 line long tables that will somewhat "emulate" the loss of precision. At least this way you'll know exactly how soon you can expect the error to become significant in your particular scenario.

 

Thanks Vlad, watching Northern Lights and dipping in the lake does not rule out doing silly things with the Lynx.

 

I don't really need to do transformations for actual angles. Most likely I could limit my rolls to a few deltas/frame. Perhaps minor turn, normal turn, steep turn. So the needed angles could be 0.89525642, 1.89919328, 4.98609928. If I could then get rid of code trying to check for orthogonal matrix after the transformation I would save a lot of time. The same "magic deltas" would be used in all three axis.

 

Because I am probably more interested in a game than a simulation I want the crafts to be upright. So there would be "gravity" pointing down all the time. The distances would also be linear, meaning that the craft becomes bigger at a constant rate instead of being a dot for ages and suddenly zoomed up for fly-by.

 

But @42bs has a point. In the long run it may be better to leave Suzy free to do graphics and use the CPU for math. Especially if I manage to squeeze out all tricks from @enthusi about how to code for the Lynx <:evil grin:>

[VladR]

I did the Delta thing once on PC when I had my 6-DOF underwater simulator game demo about 15 yrs ago. Even using doubles, very quickly the precision deteriorates.

 

Problem is, it's non-linear and really dependent on how frantic the action is. You can fly forward for 30 seconds and it's all fine, but when action becomes frantic and you need to do dozen maneuvers within half second avoiding shots from 3 ships, which is exactly where you need it most, it barfs on you.

I've lost more time debugging and creating workarounds than it was worth the performance it saved.

 

People don't mind 5% lower framerate as much as they mind occasional glitch - like once in 10 seconds. The cost of the workarounds for those glitches will be certainly substantial on 6502.

 

Of course, I'm not saying it's impossible to design a useable system for 6502. It's just not worth the effort in my opinion. You can have giant LUT tables and require the game to use 1 MB, so I really see no point.

 

Then again, if you have the itch and simply must do it, it's different - you do it for fun

 

 

[+karri]

I believe the point of "magic angles" is that a turn left followed by a turn right would bring back the original matrix. So for these special angles the cumulative error is small enough to be ignored. This could be true for the lifetime of an object on screen. If I can keep the object there for tens of seconds it should work. The UI would be limited to allow only these special rotations and tilts that don't allow errors to accumulate.

[VladR]

Well, I was doing full-blown 6-DOF simulator, with complete freedom of movement, so it's quite possible that if you restrict rotation to only certain axis, the total precision will get bumped up as you're not accumulating errors from multiple axis.

 

Are you using fixed point ? How many bits ?

[+karri]

41 minutes ago, VladR said:

Well, I was doing full-blown 6-DOF simulator, with complete freedom of movement, so it's quite possible that if you restrict rotation to only certain axis, the total precision will get bumped up as you're not accumulating errors from multiple axis.

 

Are you using fixed point ? How many bits ?

Just 16 bit 2's complement integer math. Resolution is only 14 bits. 0x4000 = 1.0.

We want to have 1.0 * 1.0 = 1.0

In hex the multipy A*A becomes ((A*A) << 2) >> 16.

0x4000 * 0x4000 = 0x1000 0000

0x1000 0000 << 2 = 0x4000 0000

By just using the high 16 bits we have 0x4000 which happens to represent 1.0

 

The "magic angles" are calculated in this same numbering system.

[42bs]

1 hour ago, karri said:

Just 16 bit 2's complement integer math. Resolution is only 14 bits. 0x4000 = 1.0.

We want to have 1.0 * 1.0 = 1.0

In hex the multipy A*A becomes ((A*A) << 2) >> 16.

0x4000 * 0x4000 = 0x1000 0000

0x1000 0000 << 2 = 0x4000 0000

By just using the high 16 bits we have 0x4000 which happens to represent 1.0

 

The "magic angles" are calculated in this same numbering system.

Actually, that's fix-point math, but doing the double-shift left kills upper bits.

For demo0006 I use the sinus table from BLL using 8bit which should be sufficient for the screen size of 160x102 pixels.

 

[Cyprian]

so is Suzy math usable?

[+karri]

It has 32 bit automatic accumulate after 16*16 multiplication. So it presents a pipeline. It also has division and qubertroot.

[42bs]

1 hour ago, Cyprian_K said:

so is Suzy math usable?

Sure it it. See the mandelbrot demo. But don't expect wonders.

[ArneCRosenfeldt]

On 12/11/2019 at 12:26 PM, VladR said:

I did the Delta thing once on PC when I had my 6-DOF underwater simulator game demo about 15 yrs ago. Even using doubles, very quickly the precision deteriorates.

 

Problem is, it's non-linear and really dependent on how frantic the action is. You can fly forward for 30 seconds and it's all fine, but when action becomes frantic and you need to do dozen maneuvers within half second avoiding shots from 3 ships, which is exactly where you need it most, it barfs on you.

I've lost more time debugging and creating workarounds than it was worth the performance it saved.

 

People don't mind 5% lower framerate as much as they mind occasional glitch - like once in 10 seconds. The cost of the workarounds for those glitches will be certainly substantial on 6502.

 

Of course, I'm not saying it's impossible to design a useable system for 6502. It's just not worth the effort in my opinion. You can have giant LUT tables and require the game to use 1 MB, so I really see no point.

 

Then again, if you have the itch and simply must do it, it's different - you do it for fun

 

 

What glitch are you talking about? Is this about ortho-normalization of a matrix (one inner product per frame -- and then cycle) ? Or do we talk about Conversion from quaternions to a matrix?

[maxxoccupancy]

I just read/heard a single remark the other day that Suzy has some rudimentary floating point capabilities, which I'd never even thought of before.  As a RISC architect/software engineer, I certainly know how to put together a small, economical floating point pipeline, but didn't expect a $179 handheld from 1989 running on AA power cells to have anything like this in its graphics pipeline.

 

Is this what you're using for those calculations?  Or the integer multiplier?  And is there any online programming manual and or diagram for the Suzy?

[42bs]

No float!