rotate 8x8 grid 22.5, 45 degrees? (IDE brainstorm)

[kisrael]

Gary W. wrote me about my Playerpal sprite drawing tool for the 2600 ( http://alienbill.com/2600/playerpalnext.html ) and wondered about rotations finer than 90 degrees, namely the compass points (45 degree) and maybe full 16-stop rotation (22.5 degrees)

 

Now this ain't gonna be exact, unlike 90 degree rotation (and even then a purist might point out that non-square pixels could be an issue)

The box just doesn't fit, so you have to fake it.

 

Theoretically, you only have to do the mapping once for each rotation, and find the "source" pixel location in the original for each pixel in the rotated version.

 

(Thought: it might be best to do this unique for each of the "3" rotations, 22.5, 45, 37.5, and then derive every other rotation from a 90 degree turn plus one of those, since doing a 22.5 degree rotation twice would probably cause the fudge factors to accumulate.)

 

So, is this a solved problem?

 

I guess there are two ways of attacking: look to games I like that do this (like Combat, and also Batari's avatar) and hand reproduce what they're trying to do...

Or I could try and look up the math, though the rounding errors will be attrocious.

[supercat]

(Thought: it might be best to do this unique for each of the "3" rotations, 22.5, 45, 37.5, and then derive every other rotation from a 90 degree turn plus one of those, since doing a 22.5 degree rotation twice would probably cause the fudge factors to accumulate.)

 

For symmetric objects that start facing up, a 67.5 degree clockwise rotation could be derived from the 22.5 degree clockwise rotation, a 90 degree clockwise rotation, and a flip about the horizontal axis.

 

I'm not sure how useful a tool to perform fractional rotates on small objects is going to be. Perhaps having a function to display a reference outline over the grid that could be rotated, scaled, and shifted by fractional amounts could be useful as an aid to someone producing differently-scaled versions of the sprite, but there's no way pure software is going to produce anything that looks even halfway reasonable. An overlaid outline would be far more useful as a drawing assist than would be a blobby mess formed by the computer's attempt at rotation.

[Robert M]

My favored technique for doing this is to define the object in the up direction using straight lines and circles arranged around the point of rotation on the graph paper. I then redraw the lines and circles at rotated position exactly the size and position and choose the squares to fill in as appear appropriate. It is sort of a manual convertion from vector line art to raster art. I trace the lines from the center to center of pixels on the straightup image. I thiink it gets the best results when rotated. If a line passes near the center of a pixel on the rotated image I fill it in. Tweaking by hand is often needed.

[Hornpipe2]

Yes, this is a 'solved' problem. But when you do a non-quarter rotation, source pixels are no longer 0 or 1 unit distant from one another per axis: they get somewhere in between. In that case you have to figure out how best to handle mapping those pixels back to screen-space. Graphics programs apply a filter to fix the results so they still look nice, but you pretty much have to draw this by hand with such a small number of pixels.

 

It may be possible to do it by 'normalizing' all distances to be at least 1, but the result still won't look nice as pixels will become >1 unit distant on the other axis. Your sprites will also grow to greater than original dimensions.

 

One alternate solution to this is vector graphics, which use floating-point by default and are not restrained to a grid like raster graphics. Too bad the 2600 can't handle that : )

 

 

But here's how you can take advantage of symmetries to reduce the number of sprites in your code:

If your object is bilaterally symmetrical you can draw n sprites to get 4*(n-1) directions. E.g. for 16 directions you draw only 5 sprites: one each facing north, north-north-east, north-east, north-east-east, and east. Everything else is then reachable purely by flips over X and/or Y axis of the appropriate sprite.

 

And if your object is symmetrical both in X and Y axis, you can save on flips. The nne sprite will be the same as the ssw, for example.

Edited September 20, 2007 by Hornpipe2

[mos6507]

The stupid thing about combat is that it tries to save space by scanning the tanks ascending or descending into the RAM buffer for vertical flip but it doesn't take advantage of the flip register. It stores the entire top (or bottom) half of rotations. For Death Derby I just store the left or right half of rotations and use the flip register. Some of the savings is lost when you try to determine whether to turn the flip register on or off but it's still definitely a net gain to do it.

Edited September 20, 2007 by mos6507