In an earlier post, I vaguely discussed creating an infinity sign using the Medusa Head sinusoid -- and other derivatives such as Protoss Interceptor patterns. But the one thing that kept eluding me was a simple ellipse.

*Example use of ellipse code**(xstart,ystart)*. Defining the semi-major and semi-minor axes is not as cut-and-dry, however. If we let

*Rx*be the horizontal radius as defined by

*abs(x-xstart)*and

*Ry*be the vertical radius as defined by

*y-ystart*, and if we let

*Vx*be the initial horizontal velocity and we let

*Vy*be the initial vertical velocity, if

*Rx=Ry=0*, then the resultant shape is simply a line along whose points our Medusa Head would oscillate back and forth across a distance of 32

*V*x/y pixels. Similarly, even if

*Rx*and

*Ry*are non-zero values,

*if*

*Vx=Vy*, the resultant shape will still be a line. Likewise, if

*Rx*and

*Vx*are both 0, or

*Ry*and

*Vy*are both 0, the resultant will again be a line. So if

*Rx*and

*Ry*are equal non-zero values,

*Vx*and

*Vy*must not be equal, and vice-versa. Similarly to how

*Vx*and

*Vy*define the slope of the line, they also affect the orientation of the ellipse. If

*Rx>16*Vy*or

*Ry<16*Vx*, the ellipse will be oriented horizontally, but if both x and y sets have been defined, the ellipse will be rotated.

Update: Turns out there's actually a slight glitch in the Medusa Head code. Offsetting

*x₀*or

*y₀*from

*xstart*or

*ystart*causes a slight shift. This was actually present in the NES code too, but you never notice it because a) it's rarely used if ever, and b) enemies usually aren't around long enough. This shift is exacerbated into a wobble when applied to the ellipse code. This isn't noticeable when working with double-precision floating points, but if you're trying to make an NES game, this could eventually lead to some annoying glitches.

And yes, that animation above could be NES-compatible using a timed priority toggle for the ball and chain sprites.