nesdev.com

I figured as much. I imagine that these values are $00 for most writable registers, and double-$00 for any register that takes double-writes, with a few exceptions such as the first and last mode 7 matrix registers that need to be $0100. So is there a reliable list of what these values are other than the official docs? If there is a list, an emulator developer could add a feature to warn on writes of incorrect values before all registers have the correct starting values.

??? SpriteBuf1 has 4bytes per sprite (X and Y positions, character data, and extra) for a total of 512 bytes and Spritebuf2 has each sprites most significant X bit and sprite size selection bit, and it is 32 bytes long. SpriteBuf1 and 2 then get DMAed to OAM during VBlank.


I don't know. He's probably making something insane.

By the way, I made the metasprite routine use 16 bits (I haven't implemented the 9th x, not y bit yet, as it currently just gets erased when storing the number in spritebuf1) and it worked flawlessly, but I tried to make it where you add XPosition and YPosition to the number in the table that gets stored in SpriteBuf1, but the assembler didn't like it.

Edit: I forgot to CLC before ADCing, but it didn't make a difference. (I'm really not sure why it would, but I tried.)

The init routine in my code (see .zip file, or my old sndoc230.zip archive (see test.lzh/test.zip within that zip)) has all the correct values per official docs. I don't know of anywhere else that lists them off. Many are zero, yes, but not all.

@Espozo: assembler error in question is because you forgot to .exportzp the XPosition and YPosition variables within MetaspriteTest2.asm. You have to have both .importzp (in the file where you want to use those variables) and an .exportzp (in the file where you declared them) for it to work.

Procs (e.g. subroutines) work the same way (using .export/.import).

Macros, however, don't work that way -- they're not procs, they're just raw code, hence why there's Macros.asm and why I put all macros in there. And I should note that for Macros.asm, it only needs to be .include'd ONCE for the macros to be universally available, which is convenient.

But back to variables: there is also a .globalzp ca65 directive which I didn't have time to explore or tinker with, but I wouldn't get too hung up on that right now.

I'll use this opportunity to point out how annoying the ca65 "zp" stuff is, specifically because the ZEROPAGE segment is only 256 bytes long, while on the 65816 you have direct page which is up to 65536 bytes long (depending on where you place it using lda/tcd). And ca65 absolutely requires a ZEROPAGE segment (incl. in the config template). For 6502/65c02 this works wonderfully, but for 65816 it's irritating. Maybe tepples/thefox have some ideas on how to tweak the template to work better with it, but I simply don't. So basically once you exhaust the ZEROPAGE segment (i.e. you exceed 256 bytes there), it's gonna start throwing errors during link-time, in which case your variables need to end up in the BSS segment (like where the SpriteBufs are).

Besides from Bad Apple, I've been working on a game called Alisha's Adventure. As to why I keep giving up on projects and starting new ones, it's because there is always that one little architectural problem that makes it difficult to program anything without rewriting a whole bunch of code.

You seem to really like female characters, but I guess I'm not one to talk? I've already shown this on the SNES Pixel Art thread, but I fixed it up a bit more. (I'm way to nitpicky for my own good. )

I think it's really funny how when you hold down the dash button against a wall how the dashing animation still plays even when you aren't moving. Also, about the plasma Grinch thing, does it use real-time sprite rotation for its limbs?

It actually rotates everything during the "LEVEL 1" screen.

No wonder it takes a while to load... (I assumed it was graphics decompression or something) How do you store all the animation for it moving? WRAM?

The rotating limbs take up half of wram. The dynamic animation system is kind've like what you described in that other thread, but instead of looking for a box for every individual sprite, it looks for a box for every metasprite.

Then in that case, it would be way easier, just like calculating x and y because you wouldn't need to have the "second y" that I made. You know psychopathic teen, have you worked on the Genesis before, because something about your art style and the fact that you are pretty much only using half of wram kind of reminds me of the Genesis. I guess the advantages to both my code that looks for tiles in vram and yours is that mine is a bit more flexible, meaning it doesn't assume every metasprite uses the same size, but I imagine is a bit more costly. (Only the sprites that are undergoing any kind of animation change are going to go through, so it shouldn't be that big of a deal.)

It doesn't assume every metasprite is the same size. It just assumes that all metasprites are rectangular.

So it allocates different sized metasprites to different sized slots?