Moderator: Moderators
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).mikejmoffitt wrote: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.
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).psycopathicteen wrote: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.
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.mikejmoffitt wrote: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.
Vertical tile scrolling is just a matter of loading and storing bytes.Sik wrote:Also wouldn't software horizontal line scrolling be faster than software vertical line scrolling? May as well do both in the CPU.psycopathicteen wrote: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.
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.Sik wrote: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.
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.Sik wrote:8 directions usually looks ugly, it's better to stick to 16 =P (which with flipping gets reduced to 5)
This was on the assumption of scrolling each column of pixels separately. Then you're moving individual bits.psycopathicteen wrote:Vertical tile scrolling is just a matter of loading and storing bytes.Sik wrote:Also wouldn't software horizontal line scrolling be faster than software vertical line scrolling? May as well do both in the CPU.psycopathicteen wrote: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.
