nesdev.org

Now, X is the object as always, Y is now the spritedef, and D points to the OAM destination. How are you able to use Direct Page for this with the SNES's dumbass HiOAM table? I don't. I reuse the X index register to do it. This requires preserving the current value of X, and it's something I could ...

I ran into the same issue while refactoring my sprite routine, actually. I had the direct page pointing to the spritedef with X and Y pointing to the current object and the OAM destination, respectively. I realized that this would only let you put spritedefs into bank 0, so I reworked the function. ...

Hmm, 9 to 1. Well, that was easy enough. Thanks everyone!

I have another note: if your attack is instant and you choose to start your sample immediately, take special precaution with the first few samples (the first 8 are what I note down). I usually do an 8-sample fade if I find my conversions getting a bit too much pop to tone down the effect. I have a ...

So right now I'm working on a few example programs for the first release of my framework. It has some imperfections here and there, but one bit that really bothers me right now is the style of VRAM address. The macros I'm using for load-time VRAM transfers use word addresses, and so do the VRAM addr...

Hmm, not sure I'd trust anything that involves WLA as an implementation detail, at least not until its 65816 support receives some bugfixes.

Pvsneslib was the first thing I toyed with when I was getting into homebrew. The library's API was lacking in places and I wasn't super impressed with tcc. Well, I was impressed in that "hey, I can write C code and get results on-screen quickly". I was less impressed with the performance a...

So I thought about this for a bit. You can have some pretty big characters with full screen height, but you'll only have the bandwidth to upload graphics for one at a time. However, you also want to be fair to both players by not preferring early updates for one over the other. So here is my idea fo...

Well, I said it was a raw tilemap editor. So it just makes plain static, low level tilemaps for use in title screens and other single screen use cases. Metatiles will come later when I write a level format.

Changing the data (BG tile map) will require some actual SNES knowledge. It's 2 bytes per tile*. Read the wiki. I would be lousy at explaining it. My SNES framework, which will have its first release in a couple weeks should be released once I work out some rough edges, includes a raw tilemap edito...

Yeah, if it sounds metallic it could just be a case of bad aliasing.

I'm placing mine at X=-255 (originally intended as a code optimization but I guess it also works to avoid the bug(?) you described).

Assuming that you're zero-initializing your RAM copy of OAM, having all other sprites in the top left corner is normal. You'll probably want to move them offscreen by setting the nineth byte of their X coordinate.

That DMA to OAM code is already there in the VBlank handler, so you don't need to write it again elsewhere. You'll notice in the comments that the number of bytes it transfers is 0x220, which is the full size of OAM, hence it transfers all sprites. Since you mentioned that SpriteBuf1 is at 0x400 and...

I understand that much. There's a low byte and a high byte. These contain data for the table having to do with telling the system how to use my sprite. As seen on the given link, it shows the record format for the low table and the high table and what the values are. But I can't find where they did...