16bit table indexing problem

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 16bit table indexing problem

Post by tepples »

koitsu wrote:The official docs [...] just tell you what each register needs to be set to value-wise on reset.
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.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

koitsu wrote:Your whole metasprite + sprite concept here seems very... I don't know. I sort of get the impression you don't understand what SpriteBuf1/SpriteBuf2 do (meaning what they're for and how the SNES uses them), but there's a 50% chance I'm completely wrong and it's just that you haven't written the rest of the code but have designed it somewhere (in which case I apologise + ignore me). But I now understand why you want to "move to 16-bit" -- because the MSB (9th bit) of the Y position of a sprite is separate from the remaining 8 bits. I now actually understand what's needed to make all of that work, but I wish I had a better idea ultimately what your goal was.
??? :| 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.
koitsu wrote:P.S. -- One of these days I wanna see what psychopathicteen has been working on for like the past 8 billion years.
I don't know. He's probably making something insane. :roll:

By the way, I made the metasprite routine use 16 bits (I haven't implemented the 9th x, not y :P 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.)
Code.png
Code Extended.png
Assember Problem.png
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

tepples wrote:
koitsu wrote:The official docs [...] just tell you what each register needs to be set to value-wise on reset.
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.
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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 16bit table indexing problem

Post by koitsu »

@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).
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: 16bit table indexing problem

Post by psycopathicteen »

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.
Attachments
Alisha's Adventure.zip
(31.56 KiB) Downloaded 536 times
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

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. :oops: )
player2.png
player2.png (1.2 KiB) Viewed 10647 times
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?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: 16bit table indexing problem

Post by psycopathicteen »

It actually rotates everything during the "LEVEL 1" screen.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

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?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: 16bit table indexing problem

Post by psycopathicteen »

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.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

psycopathicteen wrote: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.)
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: 16bit table indexing problem

Post by psycopathicteen »

It doesn't assume every metasprite is the same size. It just assumes that all metasprites are rectangular.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: 16bit table indexing problem

Post by Drew Sebastino »

So it allocates different sized metasprites to different sized slots?
Post Reply