How does the scrolling in this game work?
Looks like it's just a timed loop that updates horizontal scroll once per scanline.
And why do most emulators get the scrolling off by 8 pixels for some scanlines?
I don't know which ones you've tried it on, but most NES emulators haven't been properly updated for ages; they're not up to recent findings (nor even have an accurate pixel renderer to begin with).
LoopyNES, Nintendulator, Nestopia, and FCEU get it correct, VirtuaNES, Nes4PC, Famtasia, Nester, JNes, and PocketNES get it wrong. How come some lines are offset by 8 pixels, while others are correct?
For one thing, the coarse (0, 8, 16, 24, 32, etc.) and fine (0, 1, 2, ..., 7) X scroll values seem to be applied at different times.
tepples wrote:
For one thing, the coarse (0, 8, 16, 24, 32, etc.) and fine (0, 1, 2, ..., 7) X scroll values seem to be applied at different times.
Coarse X scroll gets updated at the (visual) end of each scanline. Fine X scroll gets updated
immediately.
(This assumes the player is positioned at the leftmost X position, and there is no curve in the map at the time)
I was stepping through the raster scroller of Slalom. Every 8th horizontal-scroll write to 2005 (@PC = 00BC) has a value 8 smaller than I would expect. This shows up in most emulators as the scanline appearing 8 pixels too far to the left, but shows up fine in Nintendulator. All the writes happen well after the BG is done rendering on that scanline.
Why does the game even display correctly in the first place, if it's writing values 8 too small every 8th horizontal-scroll write?
I've figured out a bit about how slalom works, but under which conditions does the game need to add or subtract 8 from the value written to the scroll register?
What stops the title screen from shaking?
I don't know anything about this game in particular, but bear in mind when examining $2005 writes that changes to bits 0-2 take effect immediately, while changes to bits 3-7 (as well as bit 0 of $2000) don't have any effect until the start of the next H-Blank (cycle 257 to be specific). Thus, if $2005 were written in the middle of H-Blank, bits 0-2 will affect the next scanline, but bits 3-7 won't take effect until the scanline afterwards. Emulators that don't use cycle-accurate PPU rendering will not correctly handle this condition.
If Dwedit is making a renderer that must be scanline-based for performance reasons (e.g. the target platform's underlying video hardware is scanline-based, and the target platform's CPU is not fast enough for a full software PPU), then sampling fine X at x=8 and the rest at x=257 should work, right?
My emulator renders complete scanlines only and still handles Slalom correctly. The time that it renders a scanline is key: currently I do this 60 PPU clocks from the beginning of a line. It uses the catch-up method, so other aspects of PPU emulation are precise, like the time of H-blank. It's definitely a workable method.
dvdmth wrote:
I don't know anything about this game in particular, but bear in mind when examining $2005 writes that changes to bits 0-2 take effect immediately, while changes to bits 3-7 (as well as bit 0 of $2000) don't have any effect until the start of the next H-Blank (cycle 257 to be specific). Thus, if $2005 were written in the middle of H-Blank, bits 0-2 will affect the next scanline, but bits 3-7 won't take effect until the scanline afterwards. Emulators that don't use cycle-accurate PPU rendering will not correctly handle this condition.
That specific detail about cycle #257 was left out of Loopy's guide, and hearing that clears thigns up a lot.
(Stuff like this should be noted in the wiki!)
Dwedit wrote:
(Stuff like this should be noted in the wiki!)
Noone's stopping you from contributing
Hmm... I wonder what kind of glitch appears, because I couldn't detect anything obviously anormal while playing this game using my emulator.
It might be a different issue, but RockNES 2.40 for Mac OS has glitches every few lines in this game. Surely you have old builds of your emulator laying around.
WedNESday's PPU emulator does everything that you are supposed to do, and the scrolls works perfectly. It could be your Sprite #0 hit emulation I suppose.
Yes, but you didn't pay attention to the version number mentioned: 2.40 (too old). We're in the 5.xx series, and I said there's nothing obviously wrong during the emulation of that game in the most recent public version.
Fx3 wrote:
Hmm... I wonder what kind of glitch appears, because I couldn't detect anything obviously anormal while playing this game using my emulator.
blargg wrote:
It might be a different issue, but RockNES 2.40 for Mac OS has glitches every few lines in this game. Surely you have old builds of your emulator laying around.
Fx3 wrote:
Yes, but you didn't pay attention to the version number mentioned: 2.40 (too old). We're in the 5.xx series, and I said there's nothing obviously wrong during the emulation of that game in the most recent public version.
Try again. In quote #1 above, you asked what kind of glitch appeared. In quote #2 above I directed you to an emulator that displays this glitch, and since it's an old version of
your own emulator, I figured you'd be likely have a copy of it (though not the Mac version).
Slalom also requires proper handling of stack overflow, as I recently found out the hard way. About 5 seconds into the title screen, it issues a JSR operation when the stack pointer register is 0, so half of the PC goes on the bottom of the stack and half goes on the top. I was passing all of blargg's CPU test ROMs even with borked stack emulation so it was tricky to find, especially since I figured a Slalom glitch was probably going to be PPU-related.
Sorry for the bump, but I wanted to tack this little bit of information onto the Slalom thread.
Cool. I also suggest that a test for this be added to Blarrg's CPU test rom, if anyone has the time and ability to update it.