Can sprite scalling be done through software?

[Drew Sebastino]

Sorry for yet another dumb question, but I was wondering if it were possible to scale sprites without the need of an expansion chip. I know that the Super FX chip was only a cpu and not a graphics processor, but was able to pull of impressive sprite scaling techniques in games such as in Yoshi's Island. Because of this, It seems possible to use the same sprite scaling algorithm used in the Super FX chip and use it on the SNES, even if it would take a huge chunk of processing time.

[Memblers]

With memory being cheap as it is, I would consider pre-rendering the sprites whenever possible. Though if you need both scaling and rotation at the same time, you could probably pre-render the rotation and do the scaling in in real-time (or some similar combination), if that helps.

[Drew Sebastino]

Thank you, and as you said, I would like to be able to have sprites that would be rotated and scaled. Do you know what equation the Super FX chip uses for sprite scaling? Sorry for all these questions, it is just that I really don't know much about programing.

[tepples]

Rotation and scaling are an affine transformation. Do a web search for linear algebra, affine transformation, and texture mapping.

[tokumaru]

In the case of an SNES without expansion chips, wouldn't it make more sense to use a set o look-up tables than to perform the actual calculations in real-time?

[3gengames]

What would be interesting to see attempted is it to be done on the PIC and then pixels written to the output. It's basically how the SFX chip works, but shove a 40Mhz PIC in there, and have it do it just off of the data base and sprites/object inside the PIC.

[psycopathicteen]

I've always thought it would be possible to do scaling as a series of shifting, with a different routine for each step.

[tepples]

Wolfenstein 3D exists. Therefore yes.

[psycopathicteen]

Toy Story exists.

[Memblers]

Yeah, look-up tables would be better than calculating. There's plenty of memory for it. If I'm thinking right, a 32x32 tile with 64 angle LUT would be 128kB (if byte-aligned). 32 * 32 * 64 * 2 (x/y position). That's not big at all.

What would be interesting to see attempted is it to be done on the PIC and then pixels written to the output. It's basically how the SFX chip works, but shove a 40Mhz PIC in there, and have it do it just off of the data base and sprites/object inside the PIC.

That would be interesting. That's one of the things I had wanted to try on NES with the PIC18 on the old Squeedo board, stuff like matrix multiplication, but the big limitation was the latency - NES had to wait between port accesses, or use interrupts and have overhead for every single byte transferred. More modern ones like PIC24 and PIC32 have a 4-byte FIFO, but even better - a DMA channel. I had wondered about that recently too, if the PIC parallel port with DMA is fast enough for the SNES to DMA transfer from it. Maybe. Even just loading out with LDA would be really practical though.

[whicker]

If you're just talking about scaling (not rotation) then it's pretty basic.

Lets say we have one horizontal line of an object of 8 pixel coordinates... 01234567
well, what would doubling twice as wide look like? 0011223344556677
what would half as wide look like? 0246
what would 1.5x as wide look like (cheaply)? 001223445667


Either it's new or not to you, but you can treat binary numbers as having a decimal point wherever you feel like.
It's called fixed-point math.

Let's say I just pick two bytes, one byte "A" represents the whole number (0..1.. up to 255) and the other byte "B" represents the fraction (0/256th, 1/256th up to 255/256th). A is 8 bits, B is 8 bits, therefore A.B is an 8.8 fixed point number.

if I set "A" to 1, and "B" to 0, I have the value 1.
if I set "A" to 0, and "B" to 64, I have the value 0 + (64/256), or just simply .25 decimal
if I set "A" to 1, and "B" to 128, I have the value 1.5 (1 + 128/256)

So when I step across horizontally starting at 0, I can just keep doing one addition, then use the whole number portion to look up what pixel number to copy over, and either terminate the loop when the whole number reaches the width of the source, or I did the multiplication ahead of time and know how many times to step... either way.

The scale factor, and this step amount are inverse (1/x), as in if the step amount is .25, it's going to be 4x wide under this scheme.

Using the example from above, adding the "0.25" every time... (0 whole + 64 / 256th)

[0 + 0/256] = pixel coordinate 0
[0 + 64/256] = pixel coordinate 0
[0 + 128/256] = pixel coordinate 0
[0 + 192/256] = pixel coordinate 0
[1 + 0/256] = pixel coordinate 1, (192+64 = 256 = generated a carry, which was added to the while number portion)
[1 + 64/256] = pixel coordinate 1
[1 + 128/256] = pixel coordinate 1
[1 + 192/256] = pixel coordinate 1
[2 + 0/256] = pixel coordinate 2
...
etc.


Now if you treat this the same in the vertical direction (work left to right each row from top to bottom), now you have a coordinate pair that points to the x and y of the source bitmap.


Further,
If you don't like scaling to start at the top-left corner, and want to make it look like it expands from the middle, count from negative to positive like this: (-4, -3, -2, -1, 0, 1, 2, 3). Scaling always expands outward from the origin (0,0)


Further,

2D Rotation around the origin (0,0) is a matrix operation, simplified:
rotated X := x * cos(A) - y * sin(A)
rotated Y := x * sin(A) + y * cos(A)

For speed, this again could be decomposed into fixed point arithmetic, this time adding both an X and a Y step amount every time, as you work from left to right each row, top to bottom.

[tokumaru]

Wolfenstein 3D exists. Therefore yes.

Toy Story exists.

As long as we're playing this game: Jurassic Park exists.

Although I feel like saying that the math behind raycasters is somewhat different from typical sprite scaling and rotation. Scaling might be similar, but the only kind of rotation found in these raycasters is that of the level map, and that's almost nothing like plotting rotated pixels.

[mikejmoffitt]

This is reminding me of the Neo-Geo's table of sprite shrinking lines. It stores which lines to drop out of an image, which could be done on the SNES / Genesis as a raster effect.

[tepples]

Can Super NES OAM even be written during hblank? I know it can on GBA, but GBA has its sprite scaling and rotation in hardware.

[koitsu]

Can Super NES OAM even be written during hblank? I know it can on GBA, but GBA has its sprite scaling and rotation in hardware.

Probably -- and could probably be combined with HDMA to do tweaky effects on sprites on a per-scanline basis (e.g. make a sprite wobbly/wavy in a sinus-like manner).