What would make this website more interesting?

[Bregalad]

Nothing beats This website's Flash Intro. You can do anything on that site, the only limit is yourself.

THIS iS AWFUL !

Out of a scale of 1 to 10, how cool would an SNES software sprite rotation algorithm be? I think I figured out a way of pulling it off. All I need is to finish the code, and test it out.

This is an interesting topic.
I did something like that for the NES a while back, too bad I lost it on my HD, but I hope it's still arround the internet. You must google something like "NES Rotation Demo" and eventually you'll find it... I don't even remember if I released the source, if I did not then it's lost and you'd have to disassemble it to figure out how it works (it sucks I know).

It is incredibly slow though. It takes like 2 seconds to compute a frame of a 32x32 image, but I didn't optimise the thing much.

The reason it's so slow is because for a 32x32 image, you have to do 32x32 multiplications of a 2x2 matrix in fixed point (that 32x32x4 = 4096 multiplications) plus fetch and write the pixel in the "complex" tiled sheme (the original image was stored in NES format too).

If you could do something like this but faster on the SNES it would sure be a cool thing.

EDIT : I didn't actually lose the demo I just changed it to become full screen and pixelized, and faster, but it looks ugly, is now glitchy, is NTSC only and I guess doesn't even works proprely on real HW... I'm stupid sometimes I wish I didn't change it and kept the original but oh well.
It's here.

I couldn't find the original on google but I'm sure someone has archived it. If someone has a link it'd be great.

[mic_]

The reason it's so slow is because for a 32x32 image, you have to do 32x32 multiplications of a 2x2 matrix in fixed point (that 32x32x4 = 4096 multiplications) plus fetch and write the pixel in the "complex" tiled sheme (the original image was stored in NES format too).

Hmm.. per-pixel multiplication? I didn't go through the source code so maybe it's doing something else than just rotating an image. Otherwise it should be sufficient to just calculate the origin, dxdx, dydx, dxdy and dydy once for the entire image, and for each pixel you only need to do two fixed-point additions. This of course assumes that all tiles in the image use the same palette so that you can safely rotate the image without the risk of color "overflow".

[Bregalad]

I doubt this method would be any more efficient than the multiplication one. You'd have of course to implement, and optimize, both in order to be sure. This quickly becomes complex.

[blargg]

We could go build our own Nesdev theme park, with blackjack and hookers. In fact, forget the park.

[cpow]

We could go build our own Nesdev theme park, with blackjack and hookers. In fact, forget the park.

I'm in!

[mic_]

I doubt this method would be any more efficient than the multiplication one. You'd have of course to implement, and optimize, both in order to be sure. This quickly becomes complex.

It should be much faster, since you only need to do something like 4 multiplications (for the origin) and 4 divisions (for the deltas) for the entire image. An 8.8 fixed point addition can be done in 20 cycles, which should be faster than any multiplication unless you've got LUTs for all the multiplications.

[tepples]

We could go build our own Nesdev theme park, with blackjack and hookers. In fact, forget the park.

Peekaboo Poker is very similar to what you suggest.

As for rotation, you need two 8.8 adds per pixel, then a texture lookup (more shifts and masks), then shifting each pixel into place. For how many pixels could this be done even at 20 fps? There's a reason that the Super NES does this in hardware.

[psycopathicteen]

For how many pixels could this be done even at 20 fps?

Same as normal pixels, just as long as there is a load time before levels and every rotation step fits in 128 kB of ram.

There's a reason that the Super NES does this in hardware.

...and only one background layer at a time.