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

Pixel lines: 224 vs. 240

Pixel lines: 224 vs. 240
by on (#95919)
What's the deal with the additional scanlines in a game? By default, the emulators always have a resolution of 256x224, cutting off the top and bottom eight rows:
Image

When I choose PAL emulation, then those lines are re-inserted, giving the game a resolution of 256x240:
Image

So, the initial suspection might be that an NTSC TV cannot display those top and bottom rows while a PAL TV can. But when I watch the Angry Video Game Nerd playing "Super Mario Bros.", the TV clearly shows all the scanlines and you are able to see two whole rows of blocks at the bottom, not just one and a half:
Image

So, if NTSC TVs are able to display all 240 pixel lines, why does that emulator option to cut the first and last eight rows away even exist in the first place? And why is it always enabled by default? What relation does that emulator feature have to a real NES and TV?

by on (#95920)
I see 8 lines cut off at the edges.

It always displays them, just normally they don't show on NTSC TV's. It's best for both sides as it'll then make sure people who make homebrew but don't know the system won't put stuff where it probably wouldn't show. I even allow 16 pixels on the top and bottom becaue I did have my games cart # start on tile (1,1) and it was off the screen on two Tv's of mine, and on on one other at the time.

by on (#95926)
The console always renders 240 scanlines, but most NTSC TVs cut some of the top and bottom, so emulators tend to crop the picture. The number of hidden scanlines varies a lot from TV to TV though. PAL video has higher vertical resolution, so all 240 scanlines are usually visible, so the emulator doesn't cut anything in PAL mode.

Personally, I find this a little stupid. I prefer to see everything the console is rendering, specially when developing, because I might accidentally leave some trash that the emulator will hide and another person with an emulator configured differently or a TV that shows more scanlines will see those unintentional glitches.

by on (#95929)
Details are also covered here:

http://wiki.nesdev.com/w/index.php/PPU_ ... difference
http://wiki.nesdev.com/w/index.php/Overscan

Furthermore, there are actual guidelines in the official developer documentation (bare minimum for the SNES/SFC) that state when developing games you should try to avoid putting anything too close to the borders of the screen (horizontally or vertically) given difference in television set/CRT behaviour and what's actually visible on-screen.

TL;DR version is: that's just the way it goes.

by on (#95931)
koitsu wrote:
Furthermore, there are actual guidelines in the official developer documentation (bare minimum for the SNES/SFC)

In the NES era, the safe area boundary was 24 pixels from the top and bottom and 16 from the left and right, according to the "background planning sheets" used during the development of Super Mario Bros. and The Legend of Zelda. TVs made in the 1970s weren't made as precisely. Nowadays, if you're developing for NTSC NES, it should be safe to put text out to 8 pixels from the left and right, 16 from the top, and 11 from the bottom.

And sometimes you pretty much have to leave a glitch, such as if you're scrolling in all four directions and your mapper has no scanline counter.

See also Overscan on Wikipedia.

by on (#95934)
tepples wrote:
And sometimes you pretty much have to leave a glitch, such as if you're scrolling in all four directions and your mapper has no scanline counter.

I disagree.

I deal with it with by abusing the sprite overflow to mask the sprites at the top of the screen and to detect the start of the frame to enable background rendering a fixed number of scanlines later.

Alfred Chicken and Felix the Cat use horizontal mirroring to avoid vertical scrolling glitches and hide the leftmost column with a PPU option and the rightmost column with high priority sprites.

Big Nose Freaks Out uses a sprite 0 hit at the bottom of the screen to disable rendering early, masking out scrolling glitches at the bottom of the screen (this method is not as efficient as the previous two, though).

See? There are many ways around the scrolling glitches, even without special mapper features. I guess it just depends on how much the glitches bother the programmer. They bother me a lot.

by on (#95935)
Big Nose Freaks Out uses DMC IRQs too.

by on (#95938)
Dwedit wrote:
Big Nose Freaks Out uses DMC IRQs too.

Oh yeah, I think that The Guardian Legend works the same way. BTW, the reason I said this method was less efficient is because it's harder to pull off (DMC IRQs + moving solid tile + sprite 0 hit = too many things to manage) and it doesn't completely eliminate the visual glitches (the solid tile used for the sprite 0 hit looks like a glitch).