This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Sprite overflow flag issue [SOLVED]

Sprite overflow flag issue [SOLVED]
by on (#158328)
OK, first off, let me say I am well aware that the sprite overflow flag is buggy. The problem is that, from my understanding of the bug, my code should be unaffected -- yet the flag is still not being set when it should be. Either my understanding of the bug is incomplete, or there is something else going on here.

The attached file has four Pac-Man ghosts in a row. These ghosts and Pac-Man are made using two 8x16 sprites. Move Pac-Man to the same scanline as the ghosts and there are 10 sprites on the line. I'm expecting the overflow flag to be set, in which case my code will cycle the ghosts' priorities and they should blink. FCEUX and a few other emulators show this behavior. However, some other emulators, and actual hardware, show a different behavior where Clyde (the orange ghost) simply disappears. I debugged it in Nintendulator and it seems indeed the flag is not being set. The question is, why not?

Here is my understanding of the overflow bug, as described on the wiki: after the eighth sprite on the scanline has been found, the sprite address will be incremented by 5 instead of 4. This is not supposed to affect the first sprite found in OAM after the eighth sprite on the line; the bug is only supposed to take effect after that. I've only got ten sprites, and the tenth shares its Y coordinate with the ninth, so Y coordinate of the ninth sprite (Clyde's left half) should be read correctly. The PPU should see it's on the same scanline as the other ghosts and Pac-Man, and set the flag. Apparently, it does not.

Is the description of the bug on the wiki inaccurate? Am I misunderstanding it? What's going on here?
Re: Sprite overflow flag issue
by on (#158329)
furrykef wrote:
This is not supposed to affect the first sprite found in OAM after the eighth sprite on the line; the bug is only supposed to take effect after that. I've only got ten sprites, and the tenth shares its Y coordinate with the ninth, so Y coordinate of the ninth sprite (Clyde's left half) should be read correctly. The PPU should see it's on the same scanline as the other ghosts and Pac-Man, and set the flag. Apparently, it does not.
Not the first sprite found after the first eight. The next entry in OAM. As is, your OAM order is PacmanL PacmanR BlinkyL BlinkyR blank blank PinkyL PinkyR blank blank InkyL InkyR blank blank ClydeL ClydeR, and because the underlined thing isn't Clyde, that's why it's not predictably being set.
Re: Sprite overflow flag issue
by on (#158330)
And not that it quite helps understanding of the overflow flag, but you can just always shift sprite priorities instead of only doing it when the overflow flag is set.
Re: Sprite overflow flag issue
by on (#158333)
Yeah, you could alternate which one is rearmost in this order:

Blinky, Pinky, Blinky, Inky, Blinky, Clyde, repeat

That way Blinky lives up to his name of being the blinkiest.

Come to think of it:

Image
Blinky is the red one. Was Blinky a koala before he became a ghost?
Re: Sprite overflow flag issue
by on (#158339)
lidnariq wrote:
Not the first sprite found after the first eight. The next entry in OAM. As is, your OAM order is PacmanL PacmanR BlinkyL BlinkyR blank blank PinkyL PinkyR blank blank InkyL InkyR blank blank ClydeL ClydeR, and because the underlined thing isn't Clyde, that's why it's not predictably being set.


Oh wow. I totally didn't notice those blanks, even when I looked in Nintendulator's PPU debugger. I suppose because I wasn't expecting them, my mind refused to notice them. Yeah, now the issue isn't surprising at all.

Apparently I'd added one ASL too many when converting the priority number to an OAM address. Removing it fixes the issue. Thanks!


Kasumi wrote:
And not that it quite helps understanding of the overflow flag, but you can just always shift sprite priorities instead of only doing it when the overflow flag is set.


I know, but the arcade version didn't have ghosts blink when they overlapped, so I consider that a last resort.
Re: Sprite overflow flag issue
by on (#158341)
Another alternative might be to just do some kind of vertical overlap test in the software, instead of trying to work around hardware bugs. What do you have, 6 objects at the most, maybe? Probably not a big deal in terms of CPU usage.
Re: Sprite overflow flag issue [SOLVED]
by on (#158342)
Yeah, I considered that too. The flag does the job now, though, so might as well stick with that.
Re: Sprite overflow flag issue
by on (#158347)
rainwarrior wrote:
Another alternative might be to just do some kind of vertical overlap test in the software, instead of trying to work around hardware bugs. What do you have, 6 objects at the most, maybe? Probably not a big deal in terms of CPU usage.

Or, just cycle them on every frame, like Kasumi said. :)

I mean, it's cool to use the sprite overflow flag for what it was intended (despite the bugs), but if you're expecting the game to run at 60 Hz even with the sprite shuffling going on, then it wouldn't be a problem to do it on every frame. Pac-Man doesn't seem like the type of game where you would be running out of CPU time.