Jump to content

karri

+AtariAge Subscriber
  • Content Count

    3,213
  • Joined

  • Last visited

  • Days Won

    1

karri last won the day on December 31 2016

karri had the most liked content!

Community Reputation

1,257 Excellent

About karri

  • Rank
    River Patroller
  • Birthday May 21

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Espoo, Finland
  • Interests
    Swing dancing. Acting, Swing dancing. Atari Lynx programming and Swing dancing.

Recent Profile Visitors

24,933 profile views
  1. It has 32 bit automatic accumulate after 16*16 multiplication. So it presents a pipeline. It also has division and qubertroot.
  2. 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.
  3. 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.
  4. 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:>
  5. Or drop power ups from the sky in multi-player mode. A small parachute with a canister slowly coming down so that the gamers have to race to see who will get it!
  6. Thank you for sharing the video. I was not able to see it through the streams as it broke now and then. It is really great to have a chance to talk with the legends who created the computer gaming industry. And meeting these people in real life is so cool.
  7. Nice! I was hoping to get time to complete the game. So far I have only tried the first level.
  8. Marss. The conditions for entering was that the entries become freeware. "All the entries submitted to the competition will be published on the event's web page (sillyventure.eu) in the respective versions and formats submitted to the organisers no later than one day after competition results publication. The authors are of course welcome to provide the "final" version of their entries later, should they decide to do so. All the entries are considered freeware. Additionally, by submitting the entries all the participants automatically agree for their entries to be published as parts of the "Silly Venture Packs" for respective hardware platforms."
  9. Looks like we will soon have more homebrew games than original ones if this trend continues.
  10. All the entries were amazing at Silly Ventures. We all have different taste. I do not get carried away by Mortal Combat or Doom. Other don't like puzzle games. That is life. Most gamers seem to like games with a little more action. Moving the lawn or dropping gems does not have a lot of excitement in it.
  11. The stream was great fun for me. We commented all entries in real time. Plus I was really happy to chat with you guys during the compo. I believe we were 60+ outsiders enjoying this. At least a few competitors were there like Turbo Laser Lynx, enthusi, me. RJ was there. Kevin and Kim from US. Plus tons of others I met at eJagfest. Thank you for an AMAZING party!!!
  12. And chocolate is important! (And I don't mean the Kylie Minogue's tune with the same name from the album "Body Language")
  13. 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?
  14. Sorry about hijacking thread. I open another one.
  15. I hope to have deterministic math. Rotate left followed by rotate right should get an identical view from where I started. As the cc65 does not use Suzy math I have been dreaming about making a 3D library that is callable from C. tgi_sprite(&Sspace1); MatrixAbsolute = &ownship.vbasis_right_x; BRotateZ(Roll & 0x1f); BRotateX(Climb & 0x1f); BMove(Velocity); if (planet_1) if (CalcScreenPos(&planet1, dx, dy, dz)) tgi_sprite(&planet1); DustRoll = Roll / 4; DustClimb = Climb / 4; DustVelocity = Velocity / 4; tgi_setcolor(1); DustFront(); DrawDust(); tgi_setcolor(2); DustFront(); DrawDust(); tgi_setcolor(3); DustFront(); DrawDust(); tgi_setcolor(4); DustFront(); DrawDust(); tgi_sprite(&Scockpit); tgi_updatedisplay(); If my math gets better by the recent stuff I read about I should have Stardreamer ready soon.
×
×
  • Create New...