I noticed that some emulators, like Nestopia, handle sprite movement out of the top edge of the screen quite smoothly. A case in point is the intro for Dragon Ball Z - Kyoushuu! Saiya Jin (Japan), in which you see the Z logo (8x8 array of 8x8px sprites) scroll off the top edge smoothly, rather than disappear in 8-pixel wide strips.
I would think that the sensible way to handle this is to interpret the OAM sprite Y position range (240 .. 255) as a signed byte value (-16 .. -1) so that it is easy to calculate that the sprite is within scanline range when in scanlines 0 .. 7. The range 240..255 is invisible as a positive value anyway, however, for 8x8 and 8x16 sprites, this could be used to place them just beyond or straddling the top edge of the screen. Dragon Ball Z seems to use this and Nestopia handles it nicely. I have been less successful with my own implementation, but most likely it is a bug at my end.
What are your thoughts on this?
Are you sure Nestopia isn't hiding the top 8 scanlines? It's pretty common for NES emulators to hide the top and bottom 8 scanlines.
In theory, it should be possible to clip a sprite against the top of the screen in software the way Solstice clips everything against the level map. But I don't think any game bothered with that. They just relied on the top 10-16 scanlines just not being visible on consumer NTSC monitors. Many games clipped as a side effect of a top status bar, and those few games that did clipping without a top status bar (e.g. Jurassic Park) did so by switching to a blank CHR bank during the top few scanlines.
If you can spare 8 sprites, you can use those to clip sprites by placing them in front. Add a ninth and you can also use that to determine when to turn on background rendering.
Joe wrote:
Are you sure Nestopia isn't hiding the top 8 scanlines? It's pretty common for NES emulators to hide the top and bottom 8 scanlines.
Not sure to be honest, but I did monitor the Y sprite attribute as the Dragonball Logo crossed the top edge and I could see the Y value go down to 0 and then wrap around to 255. I'll need to test further
tepples wrote:
If you can spare 8 sprites, you can use those to clip sprites by placing them in front. Add a ninth and you can also use that to determine when to turn on background rendering.
The logo is a composite 64x64 pixel sprite (save perhaps for missing corners since it is circular) and hence most likely, all sprites are used up. The background is split via the Bandai FCG mapper's IRQ counter, so that the bottom is a rolling sea, whilst the top part shows clouds scrolling out off the horizon. Hence, I doubt it is using IRQ trickery for the top 8 pixels, but I could be wrong.
colinvella wrote:
I would think that the sensible way to handle this is to interpret the OAM sprite Y position range (240 .. 255) as a signed byte value (-16 .. -1) so that it is easy to calculate that the sprite is within scanline range when in scanlines 0 .. 7. The range 240..255 is invisible as a positive value anyway, however, for 8x8 and 8x16 sprites, this could be used to place them just beyond and straddling the top edge of the screen. Dragon Ball Z seems to use this and Nestopia handles it nicely. I have been less successful with my own implementation, but most likely it is a bug at my end.
No, the sprites simply do not wrap. Games rely on the fact that placing a sprite at Y=255 makes it appear
offscreen.
As stated, on NTSC the top/bottom ~8 lines are hidden, so the problem isn't visible with 8x8 sprites. On PAL the whole screen is visible, and you can see sprites cut off in games with vertical scrolling.
colinvella wrote:
Not sure to be honest, but I did monitor the Y sprite attribute as the Dragonball Logo crossed the top edge and I could see the Y value go down to 0 and then wrap around to 255. I'll need to test further
Lots of games places sprite Y anywhere from 239 to 255. That doesn't mean they're trying to make them appear at the top of the screen. The NES
doesn't do that. All of these Y values mean "offscreen".
It might be convenient for a game to use that whole range of numbers, e.g. you could have an enemy that wraps around as it moves off the top and returns from the bottom, so you're going to see games that do it. It doesn't matter, though, because no sprites from that range will display.
I think colinvella is asking whether it would be a nice augment (the same as the "allow more than 8 sprites per scanline") to treat slightly-negative Y scroll values as off-the-top.
To which I basically have three thoughts:
1- Games probably don't actually comply with that definition, but you won't know if you don't try it
2- It should really only be thought as applicable to PAL consoles anyway, since NTSC televisions already treat small positive values as off-the-top.
3- There should definitely be a toggle for "authentic" behavior instead of "better than reality" behavior.
Oh sure, as an option that's not on by default it's perfectly reasonable.
It would still apply to NTSC cropped output when in 8x16 mode, too.
rainwarrior wrote:
Lots of games places sprite Y anywhere from 239 to 255. That doesn't mean they're trying to make them appear at the top of the screen. The NES doesn't do that. All of these Y values mean "offscreen".
It might be convenient for a game to use that whole range of numbers, e.g. you could have an enemy that wraps around as it moves off the top and returns from the bottom, so you're going to see games that do it. It doesn't matter, though, because no sprites from that range will display.
Thanks for the clarification. As suggested in another comment, it was mostly a consideration about an aesthetic improvement provided by the emulator, such as, for example, the ability to allow unlimited sprites and not signalling an overflow to prevent flicker (which I am aware, may actually break some games that rely on overflow).
I will look into the idea of clipping the top 8 rows of pixels.
lidnariq wrote:
I think colinvella is asking whether it would be a nice augment (the same as the "allow more than 8 sprites per scanline") to treat slightly-negative Y scroll values as off-the-top.
To which I basically have three thoughts:
1- Games probably don't actually comply with that definition, but you won't know if you don't try it
2- It should really only be thought as applicable to PAL consoles anyway, since NTSC televisions already treat small positive values as off-the-top.
3- There should definitely be a toggle for "authentic" behavior instead of "better than reality" behavior.
Pretty much on the same wavelength there. Indeed, I have already implemented the 8 sprite per scanline override, but as an aesthetic option that is disabled by default.
A lot of games would need to be hacked to output these negative values. I know that the metasprite decoder in Haunted: Halloween '85 just skips any horizontal strip whose top isn't within 1-239 pixels from the top of the screen.
Incidentally, I can confirm that Nestopia, for instance, clips both the top and bottom 8 pixels, regardless of mirroring mode, scrolling etc. That explains why I couldn't eliminate a number of artefacts.
The "clipping Nestopia does" is under Options -> Video. Specifically, you're allowed to define the visual screen area for both PAL and NTSC based on horizontal (scanline) and vertical pixel row. The defaults are:
PAL: Left = 0, Right = 255, Top = 1, Bottom = 239
NTSC: Left = 0, Right = 255, Top = 8, Bottom = 231
This looks correct (i.e. like correct behaviour) to me.
Quote:
This looks correct (i.e. like correct behaviour) to me.
Nope, PAL should default to Left=2 and Right=253, and I believe to Top=0.
On PAL NES (2C07) and PAL famiclones (6538), the top scanline (the one on which sprites are never shown) is all black. Anyone with a copy of 240p test suite can verify this, like Eugene.S
viewtopic.php?p=173764#p173764
Technically overscan is a different matter than blanking though. Emulator's clipping settings control the amount of overscan. It could be that forced blanking of the top scanline on PAL NES is where Nestopia's default setting originates from, though (and obviously differentiating overscan/blanking makes no difference to the end user).