nesdev.org

Is it really that hard to use a single routine that draws the same metasprites both normal and flipped? Can't you just XOR each sprite piece's X coordinate with a zero page variable that can be set to $0F or $1F before adding it to the metasprite's X origin point?

tepples wrote:Is it really that hard to use a single routine that draws the same metasprites both normal and flipped? Can't you just XOR each sprite piece's X coordinate with a zero page variable that can be set to $0F or $1F before adding it to the metasprite's X origin point?

My routine that draws sprites handles flipping dynamically. I can't remember the details right now, but the trick is indeed XOR'ing the coordinates with some ZP variable.

tepples wrote:Is it really that hard to use a single routine that draws the same metasprites both normal and flipped? Can't you just XOR each sprite piece's X coordinate with a zero page variable that can be set to $0F or $1F before adding it to the metasprite's X origin point?

It's not hard... It's just slow. The problem arises if you are using 16-bit coordinates (I mean for off-screen activity). Unless you are absolutely certain all of the sprites that make an object will fit on screen, you have to do 16-bit arithmetic with the origin point and individual sprites. So adding 8 pixels is actually adding $0008 to the origin point. With XORing for flipping, you have to add $FFF8 to the origin point. This requires you to perform XORing on two bytes, which in the end, can slow things down a lot. A lot less cycles are involved with A) hardcoding the high part of the 16-bit addition, and B) just subtracting instead of calculating an opposite to add.

Celius wrote:With XORing for flipping, you have to add $FFF8 to the origin point. This requires you to perform XORing on two bytes

I get away with XOR'ing only the low byte by displacing the origin by 128 pixels in both axis. This way all sprite coordinates are positive, even after you XOR them, so there's no need to XOR the high byte (it's always 0). There's of course the added cost of subtracting 128 from both coordinates, but maybe that can be incorporated in the part that calculates screen coordinates by subtracting the camera's position from the object's position (i.e. just subtract an additional 128 pixels).