Direct PPU rendering possibilities?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Direct PPU rendering possibilities?
by on (#236892)
Hello everyone. So currently I have somewhat bare bones PPU implementation which parses pattern tables and nametables and displays them. I do this in a direct rendering mode - just scan the nametables, stitch the patterns and display everything. My goal is to emulate Donkey Kong at first. I do not care about scrolling and other stuff at the moment.
It works kinda well to display at least the title screen of most simple games(Balloon Fight, Lode Runner, fails to display Donkey Kong's title screen though). Here's an example:
https://puu.sh/D8Tns/d6d86f6c4e.png

My main issue which I only found yesterday is that writes to control register to select appropriate pattern table are done multiple times in one frame thus messing my display output. So for example nametables are set to render patterns from 0x1000 and then set to 0x0000 and because I render in one sweep - I get the wrong patterns as my control bit is rewritten with the last value.

That's okay, I'm gonna write a proper, cycled, scanlined renderere now as I've gained understanding of how PPU works at least however I still remember reading here and there that direct rendering approach should work on the most simple games. Am I right or wrong in this regard? Could I push direct approach more forward or should I just abandoned it ASAP and switch to a proper method?

MY goal again is to have Donkey Kong simulated perfectly. I am aware of all the PPU difficulties so I wanna stick at first with something complete. Any advice is appreciated
Re: Direct PPU rendering possibilities?
by on (#236908)
Whole-Screen-style rendering will be good enough even for games like Mega Man 2, but will fail badly on Super Mario Bros.

And literally rendering "scanline-per-scanline" will even fail on Marble Madness, which uses timed code to switch pattern tables twice per scanline so it can display the level from one table and the text from another.

For now, you can pick a time, such as the center of the screen, to sample the state of the PPU registers, then you will have information from a time where it would be rendering.
Re: Direct PPU rendering possibilities?
by on (#236909)
A line by line renderer isn't that much more complex than a full screen one... Instead of rendering a full screen every 89,342 PPU cycles (better count time in PPU cycles, to avoid fractions), render one scanline every 341 PPU cycles. It's still far from being accurate, but the chances of raster effects working will increase a lot.
Re: Direct PPU rendering possibilities?
by on (#236910)
Honestly, I moved to pixel-by-pixel rendering on the second day of making my emulator.
There just way too much stuff that's way too abstract to get working if you don't "think like the PPU".
Re: Direct PPU rendering possibilities?
by on (#236928)
LukasP: I don't see any raster effects going on in Donkey Kong's title screen... what are you seeing?
Attachment:
donkey-kong-mesen-ppu-viewer.png
donkey-kong-mesen-ppu-viewer.png [ 21.22 KiB | Viewed 5726 times ]


Everyone else: This was a complaint about ?bad? documentation on the wiki, where we explicitly encourage people to use games like Donkey Kong and Lode Runner to make sure that their understanding of the PPU and emulation of the PPU is right before they a higher-accuracy renderer. Saying "don't bother with a all-at-one-go rasterizer" isn't useful advice if their foundations are unsound.
Re: Direct PPU rendering possibilities?
by on (#236933)
Thanks everyone for chiming in about suggestions.
@lidnariq on donkey kong I see this as a title screen: https://puu.sh/D94Z5/1fc79dc792.png
And this once the game starts to play itself: https://puu.sh/D94YS/b515ee0ca2.png

My emulator passes nestest rom recommended in wiki by 100%. I am mostly thinking about mirroring as I may take poor choice of doing so at some place probably.

I also agree on your recommendation to first understand the simpler thing. Now as I've made at least the most basic bare bones direct renderer I have much better idea how PPU makes stuff happen and reading pixel-by-pixel documentation makes a lot of sense now so it definitely was not a waste of time