Sprite shearing to fake rotation

A radian is the angle whose arc length is the same length as the circle's radius. For example, if something moves through an arc of 0.4 radians, it'll have moved through a distance 40% of that to the center. If your game has 16-direction movement, there's a gap of (2*Pi/16) = about 0.4 radians between positions. For example, if something has 16 frames of rotation and a lever arm 20 pixels long, the end will move by 8 pixels between one angle and the next.

In this figure, an angle close to 22.5 degrees or 0.4 radians is marked in red, and a distance of 40 percent of the radius is marked in green.



Now say I have something spinning on an off-center axis, such as a ball on a chain or a character swinging on a trapeze. From the axis of rotation to the active part is 20 pixels. But with 16 frames of animation (8 stored, 8 flipped), that's still about 0.4 radian per frame. So when the object rotates through 1/16 of a circle, its active part instantly moves about 8 pixels, enough to confuse collision detection, eject the object the wrong way, and cause it to glitch through a wall.



I could try shearing the rotating sprite by sliding the 8-pixel strips. This is analogous to how games use "Y offset per column" background modes of the Super NES PPU and Sega Genesis VDP to fake rotation; psycopathicteen could tell you more about these modes. Sliding each strip by 1 pixel works for up to 1/8 radian (7.16 degrees) either way.



Or I could try decoupling the collision position from the display position so that the active part moves smoothly despite discrete angle changes in the sprite.

This is neat, but in the context of the Famicom/NES what would be the best way to set about implementing the idea without eating a lot of cycles figuring out how to position sprites that compose a larger meta-sprite in order to achieve the smoother rotation? To slide individual rows could be done I suppose, but vertical strips of pixels would mean eating up a lot more CHR in order to fit these modified tiles, unless you propose modifying CHR-RAM directly for this purpose, though such an operation would not be very quick, I would presume.

I'm guessing you simply use tables.

Yeah, it wouldn't make much sense to do this if it requires new graphics anyway. If this was e.g. moving the individual tiles of the sprite separately, it'd make more sense (indeed Treasure did this on Yuu Yuu Hakusho, albeit for scaling).

EDIT: I always keep up mixing the names of the two Yuu Yuu Hakusho games on the system -_-'

You could use the CPU to do software vertical scrolling, while doing horizontal scrolling with the oam x coordinates. Of course, you'll need enough vblank time to write the sprite patterns to vram.

Try doing the horizontal scrolling thing with several sprites and you'll see how messy it gets (and you'll probably run out of cycles if you try to use a general approach, you'll need to impose some special restrictions). Also that assumes the use of CHR-RAM, if you use CHR-ROM it won't work since you can't generate graphics on the fly (obviously).

Also wouldn't software horizontal line scrolling be faster than software vertical line scrolling? May as well do both in the CPU.

A metasprite in such an engine is stored either as a set of 8xn pixel columns (if it is wider than tall) or as a set of nx8 pixel rows (if it is taller than wide). A shear of +1/8 or -1/8 would slide an individual row or column of 8x8 pixel sprites by one pixel. They'd be slid around in OAM, not in CHR RAM, which means this technique would work as well with CHR ROM assuming fine-grained bank switching. Compare to what's done in the first two levels of Battletoads. The walkers' legs in level 1 are sheared for smooth movement, as is the rope in level 2.

Shall I draw another illustration of this?

So what you want seems to be what I mentioned: move around the individual sprites to make the illusion of a smoother animation (even though the actual amount of graphics is smaller).

Something like in here? (but possibly with intersecting sprites so gaps aren't obvious)
http://www.youtube.com/watch?v=e6z14xfCHV4#t=147s

Or heck, something like the swinging wires here:
http://www.youtube.com/watch?v=YptU9ig9R9A#t=14s

So you're suggesting to shear a sprite into two or more sprites as a tween between two key sprites that are rotations of each other? I guess it's possible, but without hardware support it sounds like it would take up a lot of probably-precious sprite resources. On the NES you can do shearing of background tiles via scrolling, perhaps.

In the example you provided pictures of, I'd say the 8-directions worth of sprites for the two components (with flipping I guess it's really 3 sprites each) are probably what I'd stick with. I would leave the inner sprite where it is, coarsely sticking to those 8 directions, and the outer sprite can move smoothly in a circle. Even though it would only have 8 rotations, the motion of its position can be very smooth. With sprites that are carefully drawn to work with a varying amount of overlap, it can look pretty good, and the smoothness of motion might make up for the lack of rotation granularity. I'm also reminded of the common vectorball technique, where sprite rotations are abandoned entirely, but the motion is quite smooth. (Edit: I just remembered the NES port of the vectorball example.)

I guess Sik is suggesting the same thing.

8 directions usually looks ugly, it's better to stick to 16 =P (which with flipping gets reduced to 5) Also even with 16 it can be quite noticeable, it depends on how fast the sprite rotates (if it spins quite fast it probably won't be very noticeable, if it spins slowly it will still be quite blatant).

EDIT: and before I forget, that dragon example has 16 rotations, not 8 =P

EDIT 2: also if the sprite is constantly spinning in a given direction you probably don't care if the sprite ever ends up aligned to the axes, so you can shift the rotation such that you only would need 4 sprites instead of 5.

Vertical tile scrolling is just a matter of loading and storing bytes.

Yes, Dragon Breed has 16 rotation sprites, none of them flipped. I wasn't referring to its sprite count, just that it is using the sprite position to get extra smoothness between the rotation sprites, and the overlap between sprites allows visual continuity between segments even though the positions are shifting irregularly.

Not aligning to the axes can have an aesthetic appeal as well, so that's a good suggestion not just for extra smoothness, but breaking up the look of 8-pointy things.

That depends on how symmetric the object is. If it isn't left-right symmetric, you need 8 anyway to produce 16, as only half of them can be computed through vh-flipping. Flipping only vertically or only horizontally produces a sprite facing the other direction.

Another game to look at for this, by the way, is Syvalion. Compare, say, the Amiga or SNES version to that of the arcade (arcade is a lot smoother but can't figure out if the sprites are significantly different), and look at the Chinese dragon's segments during movement.

Yeah, the game is similar to Dragon Breed (which I own :-) ) in that it has a Chinese dragon. HAI I LIEK DAGRONS. I give them milk and sugar and in return they give me good luck and the ability to manipulate water. (This line added just to try and get Tepples to go on a link spree, probably involving pictures of Spyro or strange child-like dragons with baseball hats carrying bento boxes while fishing).

This was on the assumption of scrolling each column of pixels separately. Then you're moving individual bits.

If you're moving only 8-pixel-wide strips, as in the example, you can move bytes at a time, or you can just move the sprites.

Shearing in both x and y directions at the same time are smoother than just shearing in one direction.

I'm developing a video game in Python that I plan to port to the NES once all the physics and gameplay elements are in place. I've implemented shearing of 8-pixel-wide strips into its graphics engine to simulate shifting 8x8 pixel sprites on the NES. The sprite sheet stores 8 frames of rotation through a half circle; these flip to 16 and shear to 48. The end result almost cannot be distinguished from hardware matrix rotation like that of the GBA.

Play video (103 kB)
(Should play in Chrome, Firefox, Opera, and VLC)

Wow, that looks really awesome! Highly innovative way to get so smooth rotation-animation and I can't wait to see the full game!

One suggestion though is that you probably should spend some more frames of animation on that turning box, because the smoother the overall animation is, the more distracting it is when it suddenly goes jerky...

Shearing on the boxes would look like this.

Yeah, I guess the only reasonable solution would be to double the amount of frames the animation has ^^;

Shearing on the boxes looks fine to me. The only thing I don't like about the boxes is the light pixels on the bottom edges in the 2nd/4th frames.

I tried that, and it didn't look quite as smooth as shearing. But I'll make sure to remove the failed attempt to antialias, as rainwarrior suggested.

The problem is that in the example you provided the jumps between different sprites is still way too noticeable to look smooth. If it spins faster it probably wouldn't matter much, but at that speed it's still too obvious.

It looks like the box is made of Jell-O.

One problem I see about the current box animation is that the original upright sprite has dithering and the sheared sprites look really really unpolished, thus a glaring dive in image quality when it starts rotating (but at 45 degree the sprite suddenly looks good again, which IMO looks even better than the upright one), so I think it's wiser to design the sprites without those "checkbox dithering", or else you may hand edit each sheared sprites to make them look better.

Really? I think the upright one looks much nicer than the 45 degree one (which looks kinda generic), but no matter which one you like better the fact that they are radically different from each other make the animation less believable.

It looks interesting, but it'd be better to the eye if the center of the rotation was the center of the block itself instead of being below it.

Now I'm thinking what kind of games the rotation would be actually useful...

Eh, in motion the dithering doesn't look as bad (probably because it's constantly changing).

Have you played or watched a video of the game where this is used? These are boxes that a (disturbingly legless) person pushes around, so they have to be animated like that.

Just as a side note, a similar effect can be done to fake scaling as well. The image has multiple scaled versions of itself, and to make the transition smoother, between them the sprites within the metasprite are themselves scaled.


Not before, but now I just wated it and apparently the video is older than the last post as there is less angles in the video than on tepple's last post apparently.

There's a newer video in the game's thread that has the new animation.

EDIT: As for the scaling trick, I'm sure I've seen it in a fighting game for another console... Characters could jump to a second, farther away plane, and the transition was made smoother by "compacting" the individual sprites closer together. I'm not sure if there was a second set of sprites for the second plane or if it was all done with "compacted" sprites. I think it's the Yu Yu Hakusho game on the Mega Drive, gotta check it out.

3D Battles of Worldrunner uses compacting for "pillar" type objects.

Yep, though there's only one set of sprites (in fact that was probably the whole point, otherwise they wouldn't have bothered with it since the only sprite that is actually involved in the transition is the hop when you switch planes).

EDIT: also the problem with this method is the added sprite overlap increases the chances of sprite overflow. Not really much of an issue on the fourth generation consoles, but definitely a huge issue for the NES where you can have only 8 tiles worth of sprites on the same line.

True. I just checked the game, and indeed it's easy to see the imperfections on the compacted sprites.

Only if you're actively looking for them, and honestly doesn't look much worse than if you did scaling the proper way. But it only shrinks the sprites down just a bit, I'd imagine it'd be much more noticeable if it shrunk down by a pretty large amount. The text in the middle at the start and end of a match actually does that, but it animates so fast it's pretty much impossible to notice how bad it looks.

Street Fighter 2 uses this technique of compacting sprites together to produce a fake scaling effect for the "Round [n]" thing at the start of the round:

It looks... okay?

In cartoons, it's common to momentarily squash an object that comes in contact with another object. This can be simulated on the NES in a similar manner to shearing: by drawing the 8x8 pixel sprites of an animation cell less than 8 pixels apart for a few frames. (Yes, this may momentarily increase flicker on the overlapped scanlines.) Do any NES games do this?

The difference is very subtle, but I think it does improve the overall perception of smoothness. The same could be done horizontally, when running into walls or other objects.

I'm not aware of any NES games squashing sprites on impact, but the concept of animating things without actually changing the graphics has been used since forever to make animations look smoother. In Anime for example, where characters are animated at 12fps or less, it's common practice to alternate background and foreground animations so that you don't end up with 2 consecutive identical video frames. If a character is moving, the same animation frame might be reused in different positions a couple of times before it's replaced by the next frame, so even though the character is in the exact same pose the result will look smoother than 12fps. This happens in video games all the time, because even if a game uses a really poor 2-frame walk cycle, the character will still "slide" smoothly over the floor.

I'm all for making the most out of the few tiles we have available on the NES, so if you can add extra animation frames just by displacing the tiles a bit, I say go for it.

Kirby in Kirby's Adventure uses the "compress self" (down) cel at the end of landing.

Zelda 2 kinda does, Link enters the crouching animation when he lands from a full height jump or fall.

It might be a small detail, but I think it makes the animation looks 10 times better.

Ducktales does this with Scrooge as well in the same situation.

So does Chip & Dale and many other games where artists had some understanding of basics of animation. The idea that tepples suggested is not in using the same basics, but in implementing it with relative sprite shifts rather than with extra tiles for the squashing frame, like (almost) all games are doing.

Another thing I thought of is combining the two: using relative sprite shifts to transition in and out of the crouch pose.

Sort of like this, but not so awful?