Sprite pixel 255

[Disch]

In my emu, I was noticing a weird artifact along the right column in Ice Climber:

http://i46.tinypic.com/acpglc.png

I traced the root of it back to how I'm emulating sprites. I'm trying to stay as close to the weird oam fetch pattern as possible... so I'm actually emulating the secondary oam buffer and all that.

The reason I get junk on the right column is because I don't determine whether a Y coordinate is "in range" after it's been moved to secondary OAM. I figure the PPU had already done the in range check when filling oam2, that it wouldn't do those same checks again when reading oam2.

So basically, oam2 has this in it:

Code: Select all

## FF FF FF    FF FF FF FF    ...

Where ## is sprite 63's Y coordinate (the last value written to oam2) Since I don't do an in range check, when rendering from oam2, this results in me drawing tile FF, with attributes FF, at X coord FF, on every scanline. Hence the column of garbage.


Then that made me think of the sprite 0 quirk... how sprite 0 doesn't hit when x=255.

And it begs the question... does the PPU even render sprites at X=255? Does it filter them out to prevent this garbage column? Or does it have some other filtering to prevent the garbage some other way?

Thoughts and/or feedback appreciated.

[3gengames]

I dunno how the PPU works, but maybe write a scanline+8 to the unused sprites and check the range so that you know not to put them up until you work out the kink in the PPU?

[Disch]

well I can hack in a "fix" easily enough. I just would rather do what the PPU actually does. Sadly since I no longer have an NES I can't test for myself =(

[3gengames]

until you work out the kink in the PPU?

[Disch]

Quoting yourself without elaboration isn't very helpful. Did I misunderstand you or something?

I assumed you were referring to the kink in my PPU emulation. In which case, what I said previously applies:

I could put in a hack to work around the problem (as a temporary solution) easily enough. But I still want to know the actual PPU behavior so I can implement a proper fix. Hence why I asked about it in this thread.

[Drag]

My understanding is that the PPU makes a fetch to sprite tile FF, but ends up discarding it and using a blank bitmap instead. The reason for fetching sprite tile FF is because OAM2 is initialized with FFs.

I don't know anything more detailed than that though, so I can only speculate from here.

My hypothesis is that the PPU is performing some kind of check on the Y coordinates within OAM2, because it needs to know which row of the pattern to fetch. It could easily check for out-of-range coordinates and replace them with a blank bitmap. In fact, it would need to in order to avoid your artifact.

[WedNESday]

GOD the jumping on Ice Breaker sucks. Its like 99% up, 1% sideways.

The line isn't visible on WedNESday and that has finished PPU emulation.

Sprites are most definitely rendered on the last pixel. Just go to the first level of Ice Breaker and walk your character to the end of the screen.