+karri Posted December 9, 2019 Share Posted December 9, 2019 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? Quote Link to comment Share on other sites More sharing options...
42bs Posted December 9, 2019 Share Posted December 9, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
VladR Posted December 11, 2019 Share Posted December 11, 2019 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. Quote Link to comment Share on other sites More sharing options...
+karri Posted December 11, 2019 Author Share Posted December 11, 2019 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:> Quote Link to comment Share on other sites More sharing options...
VladR Posted December 11, 2019 Share Posted December 11, 2019 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 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 11, 2019 Author Share Posted December 11, 2019 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. Quote Link to comment Share on other sites More sharing options...
VladR Posted December 11, 2019 Share Posted December 11, 2019 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 ? 1 Quote Link to comment Share on other sites More sharing options...
+karri Posted December 11, 2019 Author Share Posted December 11, 2019 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. Quote Link to comment Share on other sites More sharing options...
42bs Posted December 11, 2019 Share Posted December 11, 2019 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. Quote Link to comment Share on other sites More sharing options...
Cyprian Posted December 11, 2019 Share Posted December 11, 2019 so is Suzy math usable? Quote Link to comment Share on other sites More sharing options...
+karri Posted December 11, 2019 Author Share Posted December 11, 2019 It has 32 bit automatic accumulate after 16*16 multiplication. So it presents a pipeline. It also has division and qubertroot. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted December 11, 2019 Share Posted December 11, 2019 1 hour ago, Cyprian_K said: so is Suzy math usable? Sure it it. See the mandelbrot demo. But don't expect wonders. Quote Link to comment Share on other sites More sharing options...
ArneCRosenfeldt Posted January 26, 2022 Share Posted January 26, 2022 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? 3 Quote Link to comment Share on other sites More sharing options...
maxxoccupancy Posted March 1, 2022 Share Posted March 1, 2022 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? Quote Link to comment Share on other sites More sharing options...
42bs Posted March 2, 2022 Share Posted March 2, 2022 No float! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.