Black line - annoying!

kode54 · Post by **kode54** » Thu Feb 23, 2006 11:34 pm

How does this overscan shifting behavior work if you enable overscan during NMI?

byuu · Post by **byuu** » Fri Feb 24, 2006 12:44 am

Good question. It probably only takes effect somewhere around the start of a new frame (or end of the current one), but the CPU-side effects (VRAM writing disabled, vblank flag being cleared again, etc) probably still occur.
That's how interlace works. It won't actually enable interlace if toggled mid frame, but it will still affect tile address lookups.

kode54 · Post by **kode54** » Fri Feb 24, 2006 1:46 am

And suddenly, we're rendering again.

Needs more definite testing, preferrably not with hardware like a capture card will likely just center the image anyway. Or not.

Gil_Hamilton · Post by **Gil_Hamilton** » Sat Feb 25, 2006 1:23 am

byuu wrote:Then you must have a PAL TV, pagefault.

More likely, he got the service mode commands for his TV and manually adjusted the scan area to eliminate overscan.

Overscan is an artifact from old TV sets. Basically, there was line noise showing up at the bottom of NTSC televisions (or something like that, been forever since I read up on it). So overscan basically draws a couple extra lines at the bottom and "shifts" the image up. If you think about it, there are the same number of vertical lines on your television with overscan on or off. If 224 lines (doubled for non-interlace) fills your entire screen, then 240 lines cannot possibly fit on it. Instead, the image is shifted upwards, so the top eight lines and the bottom eight lines are cut off. At least, this is what happens on NTSC televisions, and I've proven that with my own TV.

Actually, it's more to do with low cost of production.
It's difficul tto adjust a set so the image EXACTLY fills the screen. Consumers tend to object far more loudly if there's a black frame than if part of the image is missing. Hence, the display hardware is intentionally misadjusted so that a good portion of the image "hangs" off the screen in all 4 directions.

The actual locations of the cropping borders will vary signifigantly from model to model, or even set to set.

Some samples from my own home include...
A TV that crops the hell out of the top of the image.
Another set that does the same thing on the bottom.
And an NTSC monitor that eats far enough into the right side that I lose characters in Chrono Trigger dialog, but provides the full 480 visible lines spec'ed by NTSC.

The last one's actually rather distracting when I'm playing certain NES games.

Post by **grinvader** » Sat Feb 25, 2006 3:28 pm

Since there's an unanswered question about PAL snes on PAL TVs:

We have large black bars at the top and bottom of the screen, and the actual display area is roughly vertically centered, varying with each set. Since the TVs are still 4:3, everything is squished.
We also have horizontal centering issues.

Gil_Hamilton · Post by **Gil_Hamilton** » Sun Feb 26, 2006 6:37 am

grinvader wrote:Since there's an unanswered question about PAL snes on PAL TVs:
...
We also have horizontal centering issues.

You mean other than the normal TV variances?

I'm curious about this one, if you can describe it, or know what causes it.

Post by **grinvader** » Sun Feb 26, 2006 5:04 pm

Gil_Hamilton wrote:
grinvader wrote:Since there's an unanswered question about PAL snes on PAL TVs:
...
We also have horizontal centering issues.
You mean other than the normal TV variances?

I'm curious about this one, if you can describe it, or know what causes it.

Nah, those are the same as yours.

It can get pretty awful... my current TV eats a great amount of the left pixel columns, and leaves a nice black vertical bar on the right. -_-
Totally screws games with big text windows like CT.

whicker · Post by **whicker** » Sun Feb 26, 2006 6:33 pm

The funny thing about CRT televisions is that they are affected by the Earth's magnetic field. You could perfectly line up the picture in a factory in China, and then ship it over to, say, Mexico and suddenly the alignment is completely off.

Also, the orientation (electron gun pointing North, East, whatever) has a minor effect on shifting the picture too.

/end side_note

CloudRider · Post by **CloudRider** » Sun Feb 26, 2006 7:29 pm

That could explains what is wrong with my mom's new Ascent™ flat CRT.

So does this mean the SNEs's native resolution is 256x224? I always thought it was 320x240 :/

Post by **Agozer** » Sun Feb 26, 2006 8:21 pm

CloudRider wrote: So does this mean the SNEs's native resolution is 256x224?

Yes.

creaothceann · Post by **creaothceann** » Mon Feb 27, 2006 8:33 am

CloudRider wrote:So does this mean the SNEs's native resolution is 256x224? I always thought it was 320x240 :/

Actually there might be several*, depending on what your definition of "native" is.

* (256x224, 256x239, 256x448, 256x478, 512x224, 512x239, 512x448, 512x478)

Post by **grinvader** » Mon Feb 27, 2006 11:24 am

creaothceann wrote:* (256x224, 256x239, 256x448, 256x478, 512x224, 512x239, 512x448, 512x478)

Well, all the higher res modes are special... native base res is 256x225 with 224 lines rendered.

creaothceann · Post by **creaothceann** » Mon Feb 27, 2006 12:18 pm

grinvader wrote:
creaothceann wrote:* (256x224, 256x239, 256x448, 256x478, 512x224, 512x239, 512x448, 512x478)
Well, all the higher res modes are special... native base res is 256x225 with 224 lines rendered.

Yep. (But wasn't it 224 lines with 223 rendered?)

stale · Post by **stale** » Tue Feb 28, 2006 12:54 am

pagefault wrote:I will fix this for $20.

get crackin'. haha

Post by **grinvader** » Tue Feb 28, 2006 8:52 am

creaothceann wrote:
grinvader wrote:
creaothceann wrote:* (256x224, 256x239, 256x448, 256x478, 512x224, 512x239, 512x448, 512x478)
Well, all the higher res modes are special... native base res is 256x225 with 224 lines rendered.
Yep. (But wasn't it 224 lines with 223 rendered?)

Well since I finally understand all that crap i'll try to make it simple:

From a base vertical res of 225 (0-224), you can remove line 0 since it's not rendered on the real hardware. (-> 1-224)
If a game doesn't compensate for that missing line, the 8x8 tile rows will be displayed like this:

Code: Select all

row 0: lines 0-7
row 1: lines 8-15
...
row 27: lines 216-223
row 28: lines 224-231

Two issues: the first pixel line of row 0 will miss (line 0 not rendered), and one line only of row 28 is displayed (some games actually start a completely different screen in that area, which makes it looks like garbage). That's why zsnes and bsnes also drop line 224 for a total of 223 lines rendered. (-> 1-223)
On the real hardware, that last line is rendered but might be cut by your TV, so you never realized it was there (garbage or not).

BUT, if the game compensates for the first line, then everything becomes fine:

Code: Select all

row 0: lines 1-8
...
row 27: lines 217-224

The first line won't miss, and there is no extra row. According to TRAC, a lot of games do compensate their VOFS by 1 this way, and it's more faithful to the hardware to render the 224th line.

I hope I have been clear enough.

creaothceann · Post by **creaothceann** » Tue Feb 28, 2006 10:14 am

grinvader wrote:I hope I have been clear enough.

You were.

Reznor007 · Post by **Reznor007** » Wed Mar 01, 2006 3:41 am

Just for the record, here's a shot from a real SNES showing the 1 line of garbage.

http://members.cox.net/rdawkins1/smwtitle.png

RealmRPGer · Post by **RealmRPGer** » Thu Jul 20, 2006 3:39 pm

The normal ZSNES WIP gives me TWO black lines, but I compile it myself, I get ONE black line. Anybody know why this is?

Post by **grinvader** » Fri Jul 21, 2006 11:05 am

"The normal zsnes WIP" uses older code than the current svn, duh. Are you even reading the commit messages to see what's being done ?