Is rotation possible on nes?

I saw a video of this game boy game: https://www.youtube.com/watch?v=AyjU4MtonZM

At 0:46 I think they rotate a sprite (or they have every possible sprite)?

Is it possibile to do so on nes?

Battletoads' intro "software renders" the flying spaceship into CHR-RAM with a scaling operation. (Check the CHR pattern pages in a debugger to watch it in action.)

A rotation would be similarly feasible. (Could probably scale at the same time as rotating too without extra complexity.)

True sprite rotation is very slow without a coprocessor. In some cases, a small amount of rotation can be faked with shearing. But usually, pre-defined rotations are stored in the ROM.

Scaling without rotation is faster because it can be done with lookup tables.

Hmm, doing a quick estimate, I think a naive fixed point 32x32 rasterizing could probably be done at 30fps?

You could keep up with a vblank bandwidth of 128 bytes per frame, I believe.

What is shown in this video is wireframe graphics. This is perfectly on a NES. Elite is a game released only with those. I did a demos myself using that, and so did other nesdev people.

My demo does not look really 3D, but I have another one on my hard disk with pre-calcluated 3D shapes and it works and looks impressive. I wanted to save it for a real game so I didn't publish this but since I don't know if I'll ever release a real game...

Another approach to rotating sprites is simply to pre-render it. Usually pre-rendering is the key of success when it comes to this stuff :p

It's 1000 times easier to bake rotation into sprites than it is to generate them on the fly.

Say you are using a mapper with 16kB of memory per bank. In that bank you can store a 256x64 8-bit bitmap image. Have all the rotatable sprites located in the middle of that 256x64 bitmap, with extra space between them. Then you can calculate the ROM address for each pixel by having X location as the low byte, and Y location as the high byte. Then fetch the pixels and convert them to planar format.

A 64x64 pixel 2bpp graphic is 1 KiB. A 256x64 pixel 8bpp graphic is 16 KiB. If you'll be wasting 94% of each bank on 8bpp sprites with huge blank spaces between them, you might as well just use the space for 16 pre-baked rotations that you can scale using a shrinking LUT.

Little Samson's character select screen have the selected character rotating.
I think it's a prerendered rotation, not made on the fly.
But it's a nice effect!!

Heh yeah it's nice but I don't think the topic is about that kind of rotation. That's just normal animation.

You'd need 3D models to do Little Samson's rotation in real time...

Pretty sure all of Little Samson is prerendered

The effect seen in Super Spy Hunter is shearing, the overhead counterpart to how Pole Position and Rad Racer draw their roads.

You can composite 4 sprites into the 8bpp bitmap, and even rotate all 4 at once that way.

By "4 sprites", were you referring to four 8x8, 8x16, 16x16, 16x32, 32x32, etc. portions of the same cel, or were you referring to four independent cels? If four independent cels, then all four would need to be rotated by the same angle, and I fail to understand exactly how this would prove useful. If four portions of the same cel, you'd need to somehow combine them into one cel after you have finished rotating them so that you don't have a bunch of blank space at each side that decreases usable overdraw. If you do not understand how rotating four cels would result in a bunch of blank space at each side that decreases usable overdraw, do you need me to make you a diagram?

I'm pretty sure he meant independent cells.

I think it's presuming an advantage for addressing texel fetches at a per-byte level, and from that premise if you're wasting a whole byte per texel you might as well stack 4 images in the same space, I guess. If you did want to rotate all 4 by he same angle at once, I would think that's an advantage too, albeit a very situational one.

For instance, if you were doing a Sonic the Hedgehog rotating bonus round as sprites, you could rotate a set of 4 different tiles all at once.

If you're using the RAM filling method, you can fill RAM 4 times faster. If you don't need 4 sets of sprites at once, you can do two sets of sprites at both 0 and 90 degrees.