nesdev.org

As you are probably aware, there is a test called "NEStress" on the nesdev site, which (partially) tests CPU, PPU, pAPU and the controllers. My issue isn't with the content of the test itself. I have only implemented the drawing of backgrounds, which works decently (yay!), but since there is no sprite implementation, I can't choose anything but the PPU test for now (just pressing enter at the start screen). There is, however, a real problem with the wavy effect which is supposed to happen at the main screen of the program. For the first couple dozen scanlines, a sort of wavy effect is used (ongoing of course, not static like in the images):

(FCEUX)


However, my emulator completely messes it up, and instead of making the first couple of scanlines very wavy, it makes the whole screen slightly wavy. Not only that, but there are some things on the top and bottom of the screen which aren't supposed to be shown (although I'm assuming this is because of the lack of nametable switching and/or lack of fine Y scroll implementation). Here's my emulator displaying the same ROM:

(My emulator)


As you may notice, the screen of my emulator doesn't wave as much the FCEUX one in the first "third" of the screen, but it rather makes the whole screen wavy in intervals of maybe 3 pixels at most

I thought this issue might be due to my PPU not being pixel-based but rather scanline-based. My PPU basically waits for 113.7 or so CPU cycles to pass, and then draws an entire scanline at once. Could this be the problem? Or is fine X scrolling perhaps badly implemented?

The code should only be messing with fine scroll for part of the screen, so if your emulator extends it to the entire screen every frame, your emulator is apparently running too fast. Look closely; is the effect over the entire screen every frame, or does it affect part of each frame, the part moving around vertically so that it looks like it's affecting the entire frame? If this, then something is preventing the code from synchronizing to vertical blanking.

blargg wrote:The code should only be messing with fine scroll for part of the screen, so if your emulator extends it to the entire screen every frame, your emulator is apparently running too fast. Look closely; is the effect over the entire screen every frame, or does it affect part of each frame, the part moving around vertically so that it looks like it's affecting the entire frame? If this, then something is preventing the code from synchronizing to vertical blanking.

Like I said before, the CPU executes 113.7~ cycles before drawing a single scanline, i.e. the PPU has to wait 431 of its own cycles before drawing a line. Could you mean this by "too fast"?

And about the effect itself, I let the NES run at 1 frame per second, and every line changes per frame, so the effect does affect the entire screen every frame. I still can't pinpoint what the problem is. Is there any way I could test this problem somehow?

EDIT:

If no one can directly help me with this issue, could someone explain how the program detects how many scanlines it needs to manipulate fine X for (i.e. how does it know that it has to start/stop making the wave effect on a certain scanline)? I think that might be a great help to solving this program.

NEStress is using a Sprite 0 Hit to determine the screen position and when to stop changing the PPU scroll. it reads the register until a pixel of sprite 0 is drawn on top of a pixel in the background which will set a bit flag in a PPU register. You will need to have this working correctly to run all NES games except the very simplest. Super Mario Bros. won't even get past the title screen without it.

Grapeshot wrote:You will need to have this working correctly to run all NES games except the very simplest.

What? Most complex games don't use sprite 0 hits at all, they use mapper IRQs for raster effects.

Grapeshot wrote:NEStress is using a Sprite 0 Hit to determine the screen position and when to stop changing the PPU scroll.

Ah, there we go. I saw something about Sprite 0 Hit in the source, but I disregarded it as irrelevant to the wavy effect. I haven't implemented any sprite functionality, let alone Sprite 0 Hit. I'll try implementing sprites first then, thanks.