About "fine x" in PPU scrolling

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
GZYangKui
Posts: 46
Joined: Wed Dec 21, 2022 6:54 am

About "fine x" in PPU scrolling

Post by GZYangKui »

In the PPU SCROLL article, I saw that the pixel in the "fine x" specified tile was rendered, and the background shift register was shifted once per cycle. Based on this knowledge, I built a class of 8 pixel pixel groups in 0-8 cycles, and then used "fine x+offset" to form an array subscript to pixel points and render each time. There was a problem if I didn't do this, because only one tile would be rendered in every 8 cycles, Each cycle generates a pixel. If fine x is not 0, then no pixel can be rendered in the last few cyclesImage
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: About "fine x" in PPU scrolling

Post by Drag »

The buffer that holds upcoming pixel data is actually 16 pixels long, not 8. The lower 8 indices will always contain valid pixel data, and the upper 8 are loaded with the next tile every 8 clock cycles.
GZYangKui
Posts: 46
Joined: Wed Dec 21, 2022 6:54 am

Re: About "fine x" in PPU scrolling

Post by GZYangKui »

Drag wrote: Wed Dec 21, 2022 2:44 pm The buffer that holds upcoming pixel data is actually 16 pixels long, not 8. The lower 8 indices will always contain valid pixel data, and the upper 8 are loaded with the next tile every 8 clock cycles.
Thanks for your reply. According to your reply, I have modified the implementation code, which looks much better now. Image
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: About "fine x" in PPU scrolling

Post by Dwedit »

Attributes look a bit off right now.

Running the Contra Demo in FCEUX, and stopping there, the Attribute Tables in VRAM were this:

FF FF FF BF AB AF AB EE FF AA AA AA AA AA AA AA
AA 00 00 00 00 00 00 00 AA 50 50 50 50 50 50 50
FF 55 55 55 55 50 50 50 FF F5 F5 F5 F5 55 55 55
FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00


If they match that, then it might be fetching the wrong bytes for attributes, or might be interpreting the bytes there incorrectly.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: About "fine x" in PPU scrolling

Post by creaothceann »

GZYangKui wrote: Thu Dec 22, 2022 2:13 am <img> https://github.com/GZYangKui/nes4j/blob ... g?raw=true </img>
The image doesn't show up for me.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: About "fine x" in PPU scrolling

Post by Drag »

creaothceann wrote: Sat Dec 31, 2022 1:18 pm The image doesn't show up for me.
I saw both screenshots while they were there.

The first was a screenshot of Contra, but there were black vertical stripes all over the screen, because only the rightmost couple of pixels of each tile in the nametable was being drawn to the screen.

The second screenshot, with all 8 pixels of each tile now correctly drawn, showed some incorrect palette attributes being drawn to the screen, like if each attribute byte wasn't being decoded into the appropriate 16x16 pixel regions (mostly, the palette used for the water was being extended upwards an extra 16 pixels). That was the screenshot Dwedit was referring to in the post just before ours.

Edit: By browsing the user's github repo (where the screenshots came from), it looks like they fixed the attribute bug. :)
GZYangKui
Posts: 46
Joined: Wed Dec 21, 2022 6:54 am

Re: About "fine x" in PPU scrolling

Post by GZYangKui »

Drag wrote: Sat Dec 31, 2022 5:44 pm
creaothceann wrote: Sat Dec 31, 2022 1:18 pm The image doesn't show up for me.
I saw both screenshots while they were there.

The first was a screenshot of Contra, but there were black vertical stripes all over the screen, because only the rightmost couple of pixels of each tile in the nametable was being drawn to the screen.

The second screenshot, with all 8 pixels of each tile now correctly drawn, showed some incorrect palette attributes being drawn to the screen, like if each attribute byte wasn't being decoded into the appropriate 16x16 pixel regions (mostly, the palette used for the water was being extended upwards an extra 16 pixels). That was the screenshot Dwedit was referring to in the post just before ours.

Edit: By browsing the user's github repo (where the screenshots came from), it looks like they fixed the attribute bug. :)
Image

Now there is a problem that when the background is obtained to the last tile in the horizontal direction, the tile in the next name table will be obtained. Through the code, I find that the two named tables are switched in the following code:
" var v = this.ppu.v;
if ((v & 0x1f) == 31) {
//coarse x=0
v &= ~0x001f;
//Switch horizontal name table
v ^= 0x0400;
} else {
//Increase coarse x
v++;
}
"
In this case, the rightmost display fault will occur
User avatar
Individualised
Posts: 310
Joined: Mon Sep 05, 2022 6:46 am

Re: About "fine x" in PPU scrolling

Post by Individualised »

I also notice that the bottom left tile of the hill on the left of the screen does not seem to be rendering properly.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: About "fine x" in PPU scrolling

Post by Drag »

GZYangKui wrote: Tue Jan 03, 2023 8:15 pm " var v = this.ppu.v;
if ((v & 0x1f) == 31) {
//coarse x=0
v &= ~0x001f;
//Switch horizontal name table
v ^= 0x0400;
} else {
//Increase coarse x
v++;
}
"
This code is OK. There's a different problem though:

On the left side of the screen, on the first column of tiles, the 8th pixel is being skipped, which is causing the extra column of pixels to appear on the right edge of the screen.
ppu_help.png
GZYangKui
Posts: 46
Joined: Wed Dec 21, 2022 6:54 am

Re: About "fine x" in PPU scrolling

Post by GZYangKui »

Drag wrote: Tue Jan 03, 2023 11:16 pm
GZYangKui wrote: Tue Jan 03, 2023 8:15 pm " var v = this.ppu.v;
if ((v & 0x1f) == 31) {
//coarse x=0
v &= ~0x001f;
//Switch horizontal name table
v ^= 0x0400;
} else {
//Increase coarse x
v++;
}
"
This code is OK. There's a different problem though:

On the left side of the screen, on the first column of tiles, the 8th pixel is being skipped, which is causing the extra column of pixels to appear on the right edge of the screen.
ppu_help.png
Thank you for your answer. Finally, I solve two problems by referring pixel rendering to obtaining pixels
Post Reply