About "fine x" in PPU scrolling
Moderator: Moderators
About "fine x" in PPU scrolling
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 cycles
Re: About "fine x" in PPU scrolling
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.
Re: About "fine x" in PPU scrolling
Thanks for your reply. According to your reply, I have modified the implementation code, which looks much better now.
Re: About "fine x" in PPU scrolling
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.
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!
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: About "fine x" in PPU scrolling
The image doesn't show up for me.GZYangKui wrote: ↑Thu Dec 22, 2022 2:13 am <img> https://github.com/GZYangKui/nes4j/blob ... g?raw=true </img>
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: About "fine x" in PPU scrolling
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.
Re: About "fine x" in PPU scrolling
Drag wrote: ↑Sat Dec 31, 2022 5:44 pmI 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.
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
- Individualised
- Posts: 310
- Joined: Mon Sep 05, 2022 6:46 am
Re: About "fine x" in PPU scrolling
I also notice that the bottom left tile of the hill on the left of the screen does not seem to be rendering properly.
Re: About "fine x" in PPU scrolling
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.
Re: About "fine x" in PPU scrolling
Thank you for your answer. Finally, I solve two problems by referring pixel rendering to obtaining pixels