tepples wrote:Perhaps the idea was that mode 7 would be paired with sprites scaled by some other process, such as a coprocessor. I've demonstrated real-time shrinking of a 32x48 pixel sprite in software at 15 fps on an NES. It's vblank limited and could thus probably be even faster on the Super NES.
The biggest problem with this though is the fact that it uses vblank time to draw it, and you need multiple copies of objects scaled at different distances instead of just one.
tepples wrote:I've demonstrated real-time shrinking of a 32x48 pixel sprite in software at 15 fps on an NES. It's vblank limited and could thus probably be even faster on the Super NES.
Which really begs the question as to why games like F-Zero and Super Mario Kart have everything pre rendered... I mean, even if you didn't have enough time to decompress the graphics, you're still saving way more space by having one frame at full resolution, and it looks a hell of a lot better.
Having 64x64 sized sprites still doesn't make any sense though. For reference, the hardware behind these games use 64x64 sprites:
psycopathicteen wrote:I think the biggest reason affine sprites are so expensive is the fact that a PPU could only access 1 pixel at a time, instead of the usual 4 pixels at a time.
I guess it looks at one pixel, uses matrix transformations to place it in the right spot, and then looks at the next pixel and does this over again? Wait a minute, if the SNES has a linebuffer, how would this even be possible? If the object was flipped upside down, it would load from the top, and then try to put it at the bottom, but this would be beyond the line buffer, unless it would somehow be able to hold the information, which at that point, you might as well be using a framebuffer. With normal graphics, it would just load the top, then place it at the top, which would be inside the linebuffer. Wait, this is obviously done for Mode 7 somehow... I'm dumb.
)