Is this issue a problem requiring attribute byte shift?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
tdondich
Posts: 14
Joined: Fri Mar 23, 2018 4:21 pm

Is this issue a problem requiring attribute byte shift?

Post by tdondich » Sat Jul 21, 2018 3:11 pm

I'm really close to implementing full fine-x scrolling, which is awesome. However, it appears I have some discoloration on certain tiles when scrolling.

So the question is, is this where the attribute byte should be different based on fine-x, or is the palette choice wrong in the correct attribute byte?

I've attached a screenshot to show what I mean.

Image

Thanks!

User avatar
nesrocks
Posts: 441
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Is this issue a problem requiring attribute byte shift?

Post by nesrocks » Sat Jul 21, 2018 3:24 pm

I didn't even know it was possible to misalign the tiles and the attributes.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

tdondich
Posts: 14
Joined: Fri Mar 23, 2018 4:21 pm

Re: Is this issue a problem requiring attribute byte shift?

Post by tdondich » Sat Jul 21, 2018 3:31 pm

Which leads me to believe that perhaps it's choosing the wrong palette based on fine-x. Just wondering if anyone saw this before or has a good idea of what it might be.

TD

User avatar
nesrocks
Posts: 441
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Is this issue a problem requiring attribute byte shift?

Post by nesrocks » Sat Jul 21, 2018 4:46 pm

My knowledge of the NES workings is recent, so I may be missing something. Nonetheless, I'm interested in taking a look at the ROM (is it just a static image, and not actually super mario bros?). I bet someone more knowledgeable will quickly tell you what's going on though.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

User avatar
rainwarrior
Posts: 7717
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Is this issue a problem requiring attribute byte shift?

Post by rainwarrior » Sat Jul 21, 2018 4:52 pm

nesrocks: OP is developing an emulator, not an NES ROM.

The bottom line: attribute rendering exactly corresponds to tile rendering, so there is no possibility for a partial match like this. I don't know what you're doing that is trying to apply different scrolling logic for attributes, but maybe try to unify them?

User avatar
tokumaru
Posts: 11519
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Is this issue a problem requiring attribute byte shift?

Post by tokumaru » Sat Jul 21, 2018 9:01 pm

The information used to calculate attribute table addresses is the exact same information used to calculate name table addresses, the bits are just organized differently:

Code: Select all

NN: name table;
ABCDE: tile's X coordinate;
FGHIJ:  tile's Y coordinate;

NT address: 0010NNFG HIJABCDE
AT address: 0010NN11 11FGHABC
AT mask: ID (00 = 00000011; 01 = 00001100; 10 = 00110000; 11 = 11000000)
Since the source of the bits that form the addresses is the same, it shouldn't be possible for them to be out of sync.

tdondich
Posts: 14
Joined: Fri Mar 23, 2018 4:21 pm

Re: Is this issue a problem requiring attribute byte shift?

Post by tdondich » Sun Jul 22, 2018 9:58 am

Could this be just pulling the wrong palette out of the CORRECT attribute byte?

TD

User avatar
rainwarrior
Posts: 7717
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Is this issue a problem requiring attribute byte shift?

Post by rainwarrior » Sun Jul 22, 2018 10:19 am

tdondich wrote:Could this be just pulling the wrong palette out of the CORRECT attribute byte?
That wouldn't explain how you managed to get 4 pixels worth of the wrong attribute on some tiles there. The whole tile should be wrong or none of it. So, whether or not you're pulling the attribute or palette wrongly you still need to solve the problem that they aren't directly linked to the tiles.

tdondich
Posts: 14
Joined: Fri Mar 23, 2018 4:21 pm

Re: Is this issue a problem requiring attribute byte shift?

Post by tdondich » Sun Jul 22, 2018 11:25 am

But one attribute byte consists of a 32x32 pixel grid, so it overlaps multiple tiles and is in 4 quadrants. And my thought is, this discoloration only happens on tiles that happen to be next to something different. In the screenshot above, the only tiles that happen to be discolored are the bricks next to blank spaces (which could potentially be a different palette). Is this thinking totally off the rails? Am I understanding attribute bytes incorrectly?

My attribute byte fetching is done via:

Code: Select all

      
      // Now get attribute byte
      //address = baseAddress + 0x3c0;
      let address = 0x23c0 | (v & 0x0c00) | ((v >> 4) & 0x38) | ((v >> 2) & 0x07);

      // Shift top 8 bits to the right
      this.attributeTableByte = (this.attributeTableByte >>> 8) | (this.vram.get(address) << 8);
And the determination of color is:

Code: Select all

// Note: x is the cycle on the scanline (x coordinate of screen
// this.x is fine X position
          if (((x % 32) + this.x) < 16) {
            if (y % 32 < 16) {
              // top left
              palette = this.attributeTableByte & 0b00000011;
            } else {
              // bottom left
              palette = (this.attributeTableByte & 0b00110000) >>> 4;
            }
          } else {
            if (y % 32 < 16) {
              // top right
              palette = (this.attributeTableByte & 0b00001100) >>> 2;
            } else {
              // bottom right
              palette = (this.attributeTableByte & 0b11000000) >>> 6;
            }
          }
TD

User avatar
rainwarrior
Posts: 7717
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Is this issue a problem requiring attribute byte shift?

Post by rainwarrior » Sun Jul 22, 2018 11:45 am

Well, my advice is to throw out that complicated attempt to determine the attribute to use via pixel location, and instead determine it earlier by the affected tile's memory address:

The horizontal quadrant is determined by address & 2 (every 2 tiles enters a new horizontal attribute quadrant).

The vertical quadrant is determined by address & 64 (every 2 rows of tiles, it enters a new vertical attribute quadrant).

These two bits are what are actually used to select the quadrant. There's no need to try and do calculations with individual pixels or fine scrolling, the information is already right there in these two bits of the nametable address of the tile you're rendering.

Post Reply