After looking around on multitudes of sites, it seems as though there are hardly any topics regarding circular motion. Hopefully, this will attempt to elaborate a little on this idea. It might seem long at first, but it really isn’t all that bad.

Let's say that you have an object in one of your programs, and you want to move it in a circle. Now, depending on your program, this section could be set up however you may like, it is simply up to you. For this example, we will be using an object defined by 7 bytes: One for type, such as clockwise vs. counterclockwise, two bytes for current location, two more for center of the circle, one for the radius, and one for the counting the amount of rotation the object has gone through, ending up with something like this:


Code:


This may not make much sense why those numbers are the way they are, but it will become clearer as we progress.

Now, to set up the movement routines. If you are a little unsure on how sine and cosine behave in each quadrant, I would recommend that you looks here: Sine and Cosine Behavior

Now, the question is, how do we use these sine and cosine values? Well, instead of using the TI-OS routines to get these values, we are going to use a LUT. We will split up each quadrant into 21 different parts, for a total of 84 parts per circle. For those of you who feel like a more appropriate number of parts is more reasonable, feel free to split it up however you like. And instead of trying to use these values as a fixed point number, which could be slow if you are programming an intensive side-scrolling engine, we are going to convert them using the formula int(128sin(θ)), where θ takes on the the values between 0 and 90 for each quadrant. To get the values we want, we can use some quick BASIC code, starting θ at 1 in order to skip the omnipresent 0:


Code:


We then chop off the first and last elements of the list, because we do not want them to be used twice. Because cosine is closely related to sine, we can just reverse the order to get the cosine list. So, once we plug these two lists into our code, it should look like this:


Code:


You may have noticed that some elements are a little off; this is just done after the main code is written; don't worry about it right now.

Now, having refreshed yourself with sine and cosine, lets take a look at some code:


Code:


Okay, now, this might be somewhat overwhelming. So let's go through this. In Rotate1, the object begins on the right end of the x-axis, because the counter location in ObjectData is set to 21. Then, as the first byte in ObjectData is 0, it will rotate counterclockwise, and increments the counter. Then, it checks to see how much it should move the object based on its origin and radius. For further reference, check the code. To do this, it shifts HL right by 7 bits, thus undoing our previous multiplication by 128, and then proceeds to add this to the origin values, storing the result in a different part of ObjectData, so that it is easier to draw this information later on.

Why did we change some values earlier? So that the motion would look smoother.

Hopefully this has been some help, I've also included an example program using this technique. If at first you do not understand, check out this program, and take a look at the commented lines. Good luck!

Example Program: Circle Demo

Any comments/suggestions?

Nice tutorial I wonder how fast it is compared the "naive" implementation, the one using a 256-bytes LUT and having the same code for each angle-offset.

Could be quite faster, as this method can also support as many parts of the circle as you would like, and completely avoids using any fixed or floating point math. Also, it is quite simple to change the radius, direction, location and other things, even while it is rotating. This is basically what was used in this program: The World's Hardest Game

Btw, you don't need an "or a" after "dec a". "dec a" affects the z flag. You can also use "sub" instead of "cp" to make the checks, then you can "inc a" instead "sub XX". And going on that, i'm pretty sure using a push/pop would actually be faster (and smaller). You could also use two "ex af,af'"s which would definitely be faster than reloading the value from ix and subtracting an immediate value. I also think it'd be slightly faster if you used jr instead of jp in NoResetCounter, since jr is faster when the condition is false. For the first quadrant, it'll be two clocks slower, for the rest it'll be faster. And smaller.

I appreciate you writing this up, it's been years since i've touched any trig. I've been a fan of using small path tables which i believe is faster but definitely not as flexible or accurate as this. So thanks

Can't believe I hadn't noticed this until now - nice work Mateo! This is a great tutorial on circle work in ASM

Thanks for the tips! I'll add them in there!

As I was thinking about what Chickendude said in my question thread, I looked to see if I could find anything helpful here.
And wow, this is awesome

Cool! Any ideas for use of this? You can make spirals, loops, zigzags, and all sorts of interesting things. Even rectangular motion, if you really wanted too. This could make circular games a little easier to program!

EDIT: As a matter of fact, I have learned some more, so I am going to edit this a little and make it more optimized and faster.

Basically it just makes it so only one LUT is required. +10 brownie points if you can optimize further!


Code: