>The brk thing is annoying

There's a doc on the main page about it. If it's not clear enough, let me know (I wrote it).


>How do I get the tile number for 8x16 sprites?

Here's an explanation of the 8x16 mode, which I hope will clear that up:

The LSB of the tile index determines pattern table selection, but otherwise, consider it to equal zero when using the tile index value to calculate the tile address for 8x16 sprites. This means that ALL pattern data used for any sprites have to be aligned to 2-tile boundaries. Hope that clears it up.


>Just a thought. The equation for the clock cycle of the sprite #0 hit
>CC = (y+21)*341 + x
>has been bugging me for quite a while. Doesn't this give you the upper left corner of the sprite, and not exactly the collision pixel?

"CPUcollisionCC = ((Y+21)*341+X)/3"

This is not to indicate that it has anything to do with calculating the primary object collision (hit) location. This formula is simply used to convert an absolute X/Y pixel coordinate on the screen, into the equivelant CPU clock cycle number at which the PPU is actually rendering that pixel.


>Would using this equation cause some problems or is that just ok?

This is how my emulator *still* does primary object collision detection, and man, I can't believe how well so many games work with this cheap implementation! Bottom line: object collision calculations can definetely be based solely on OBJ 0's Y coordinate. When you need to address your emulator's scrolling issues however, make sure object 0 collisions are infact working properly.