nesdev.org

He's generally talking about the physics, not the graphics or special effects. The actual physics calcs are probably doable, but they'll be a fair bit slower than the snes's if you went with a direct translation. 32-bit adds aren't very 6502-friendly. If it's doing any serious multiplication, that's...

Assuming the doc you quoted is correct, the BG uses the B set when in 8x16 mode, last set written in 8x8 mode

When in hblank, it reads the tile index from OAM, and then reads the actual pattern table data into an internal 16 byte buffer (2 bytes of pattern data per sprite, 8 sprites). In the 2C02 Technical Reference, these are referred to as Memory Fetch Phase 129 through 160. When rendering the visible por...

As others have mentioned, your sprite rendering is Doing It Wrong if you're having issues with when the switch is supposed to be. When fetching the 8 tiles for the sprites during hblank, you use the A regs for 8x16. Anything else, you use the B regs. The two get accessed at completely different time...

Mott's covered most of this. Disclaimer: the following is pretty specific to the US, I am not a lawyer, etc. Copyright covers a particular implementation (an idea fixed in a tangible medium, such as a rom chip, hard drive, book, etc), patents cover a process or algorithm. The difference between the ...

Your use of ++ twice in one expression is undefined. While the function call itself is a sequence point, there is no guarantee regarding the order the calls are evaluated in. You should explicitly adjust the PC afterwards, either using gcc's statements as expressions extension, or some other bit of ...

As far as simplicity goes, running it out of IRQ on some CPU-timed mapper would be the most transparent. you'd lose two cycles to the interrupt sequence and RTI, and another 6 to saving and restoring A across though. Might not be workable, as your main code would then get 12 cycles out of every 113,...

I've implemented the 8.8 approach, works rather nicely, though it certainly isn't fast. I think the cycle count came out to something around 200-300ish per channel you're doing it to, on top of any other work you might be doing.

$4016 and $4017 are internal as well, so I think they're free of real bus conflicts. IIRC, CopyNes stuffed it's bios at $4xxx.

The trick to fast matrix multiplies is knowing what's in your matrices, and thus where all the zeroes are.

If you think the basic transforms are bad, you should see all the stuff that goes on after you get the thing projected. Perspective-correct interpolation is a lovely mess.

Clipping and culling are two different things. If you restrict things to convex polygons, and decree that no objects shall intersect, then backface culling is all you need. Culling is the elimination of entire polygons, due to them being outside the view frustum or backfacing. Usually pretty fast. C...

Considered using MMC5? or are you already using it? The multiplier would probably be handy. Pretty much everything comes down to a ton of dot products. If you can keep the space around, you probably want to try and avoid using eulers for all rotations, as there are a variety of issues with them. The...

For this one I have a set of macros, but only for the commands, not the note data.

The quality of your triplet timing generally comes down to your tempo and time signature, and how well 60 divides into it

That assumes one is using rows, rather than an MCK style input, but your point is of course valid. That would be why bloopageddon has *another* extended command telling it how many bits are note, and how many are length. Length goes through a lookup table, and for repeated sequences, can apply a per...

What I was referring to wasn't transposing per se, as you still ended up with the same audio output. Picture a system, where notes are packed into 8 bits, 4 bit tone, 4 bit length/cmd. Tone 0-E would pass through, F would indicate a rest. lengths 0-C would refer to whatever set you wanted at the tim...