Of course, such a method would have some limiting factors:
- A smoothly-rotating sprite whose rotation calculations are rendered on the CPU wouldn't have the benefits of bi-linear or tri-linear filtering, resulting in a rather jagged, pixelated-looking image during parts of the rotation process.
- While, at the very least, bi-linear filtering could be achieved via CPU rendering as well, would that even be feasible in the early-to-mid 90's?
- Technically, with the rise of 3D accelerators, you could get bi-linear filtering by putting the sprite on a planar polygon and have the 3D accelerator rotate the polygon, thus simultaneously achieving a rotating sprite as well. However, to my knowledge, such a feature would only be available on more advanced - and, thus, more expensive - 3D accelerators.
- Depending on the angle and perspective the rotating sprite would need to be viewed in, it may prove more troublesome than any space savings since you'd still need an animated portion to give a convincing illusion of a rotating object. In fact, for some sprites, like people, perspective could force the sprite to be hand-animated anyways in order to achieve the illusion of rotation.
- How hard would it be to code rotating sprites in the early-to-mid 90's on MS-DOS machines? Would the increased processing requirements and the space savings - if any - be worth what could be gained?