PPU Rendering

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
PPU Rendering
by NESmongoose on 2007-11-19 (#28477)
Hi.

I'm currently attempting to implement the PPU unit and was hoping that I could get some feedback on the method I am planning to attempt.

I have a CPU which executes for a certain number of cycles and then deals with any cyclic tasks that need dealing with, before beginning the execution of instructions again.

After reading posts on this board, it seems like it might be a good idea to have it so that if enough CPU cycles have passed for a scanline to be output, get the PPU to build up the next scanline and output it to the display?

If this method worked out ok, I guess for background rendering i'd need to

* grab all the pattern table information relevant to the current line, convert the layers obtained into 2 bit color form

* grab the colour values for the relevant line from the attribute table

* Output this to the display using the relevant palette entries.

For sprite rendering I think it'd work in a similar way, substituting OAM for the attribute table.

Also, i've seen people talking about scanline rendering and tile rendering. Am I right that scanline rendering is the method I talked about above and tile based rendering is the method where graphics are output to the screen a tile at a time?

If this is the case, i'm guessing that the scanline approach will result in more accurate emulation due to register and memory values changing between lines etc?

Sorry if this seems a bit unreadable. Hopefully it makes some sense.


Thank you very much.

:D
Re: PPU Rendering
by tepples on 2007-11-19 (#28478)
NESmongoose wrote:
Also, i've seen people talking about scanline rendering and tile rendering. Am I right that scanline rendering is the method I talked about above and tile based rendering is the method where graphics are output to the screen a tile at a time?

If this is the case, i'm guessing that the scanline approach will result in more accurate emulation due to register and memory values changing between lines etc?

Correct. But for a few games, you'll need to simulate the effect of the CPU changing PPU or mapper registers in the middle of the scanline.
Re: PPU Rendering
by WedNESday on 2007-11-19 (#28485)
NESmongoose wrote:
Also, i've seen people talking about scanline rendering and tile rendering. Am I right that scanline rendering is the method I talked about above and tile based rendering is the method where graphics are output to the screen a tile at a time?

If this is the case, i'm guessing that the scanline approach will result in more accurate emulation due to register and memory values changing between lines etc?


Stop right there and go straight for cycle/pixel accuracy. You would go for it if you knew that it has become the standard for all new NES emulators.

by blargg on 2007-11-19 (#28495)
Care to enumerate the various levels of PPU accuracy? You can render the entire screen at once, which causes glitches for most games. You can render one scanline at a time, which works well for a majority of NES software. What does rendering one pixel at a time mean? Nintendulator accuracy, with all the internal shift registers and memory reads at specific times, or something less demanding? And is there something beyond this too (assuming Nintendulator isn't perfect)?

by tepples on 2007-11-19 (#28496)
blargg wrote:
You can render one scanline at a time, which works well for a majority of NES software. What does rendering one pixel at a time mean? Nintendulator accuracy, with all the internal shift registers and memory reads at specific times, or something less demanding?

There is a "catch-up method" that's pixel-accurate in the sense of Nintendulator but more cache friendly. Let the PPU lag several scanlines behind the CPU most of the time. Whenever the CPU writes to the PPU, the emulator should "catch up" the PPU, that is, render all pixels between where the PPU was and where it is. Whenever the CPU reads a PPU register on a scanline that could affect the output of that register (for example, a $2002 read with sprite 0 or a line with 8 or more sprites in the way), "catch up" the PPU.

Quote:
And is there something beyond this too (assuming Nintendulator isn't perfect)?

Nintendulator emulates an RGB PPU like the one in a PlayChoice, which lacks the color encoding artifacts that Blaster Master and some other games use to create the illusion of more colors. Nestopia emulates an NTSC PPU, but Nintendulator doesn't include this.

My advice: Make one to throw away. That is, implement scanline rendering first. Once you get Balloon Fight and Super Mario Bros. halfway working, you should know more about the issues.

by WedNESday on 2007-11-19 (#28499)
blargg wrote:
Care to enumerate the various levels of PPU accuracy? You can render the entire screen at once, which causes glitches for most games. You can render one scanline at a time, which works well for a majority of NES software. What does rendering one pixel at a time mean? Nintendulator accuracy, with all the internal shift registers and memory reads at specific times, or something less demanding? And is there something beyond this too (assuming Nintendulator isn't perfect)?


That's what I mean, 'Nintendulator' accuracy (or whatever is better), and let's not call it that. NES accuracy is better.

(Please let's not turn this into an 'what is meant by accuracy' debate blargg)

by Zepper on 2008-02-11 (#30783)
Assuming the hardware accuracy, what PPU cycle does the background rendering start? I mean, the first pixel is rendered.