I have read that de top 8 and the bottom 8 scanlines is only a ntsc fact, so the metodh por implementing it (at least in ddraw) is to set source surface top += 8 - bottom -= 8? Cos that is what im doing.
thanks.
thanks.
My favourite pet project...
Take a look at what FCEUltra does. It lets the user decide how many scanlines are visible for both NTSC and PAL emulation. On the TVs/Monitors that I use, the whole NES screen is visible, except for several scanlines at the top. So, I think giving users the choice is the best solution.
No sense in hardcoding your emulator to behave just like a Zenith TV.
Take a look at what FCEUltra does. It lets the user decide how many scanlines are visible for both NTSC and PAL emulation. On the TVs/Monitors that I use, the whole NES screen is visible, except for several scanlines at the top. So, I think giving users the choice is the best solution.
No sense in hardcoding your emulator to behave just like a Zenith TV.
ccovell wrote:
Take a look at what FCEUltra does. It lets the user decide how many scanlines are visible for both NTSC and PAL emulation. On the TVs/Monitors that I use, the whole NES screen is visible, except for several scanlines at the top. So, I think giving users the choice is the best solution.
The most accurate thing to do, short of emulating NTSC artifacts, is to draw the entire NES display texture (256x240 pixels) into a 588x480 quad, and then draw an 640x480 pixel quad containing an overlay texture representing the TV border on top of that. For PAL you'd draw it into a 704x480 quad and then overlay a 768x576 pixel TV border.
Quote:
No sense in hardcoding your emulator to behave just like a Zenith TV.
Unless my monitor is made by LG (formerly Zenith). I can't get it to not act like a Zenith because it is a Zenith
Whenever I played on a certain old Mitsubishi TV, my NES always displayed the bottom 8 pixels, as well as an additional 8 pixels of vblank below the bottom. It cut a significant portion at the top, which even included the super mario bros 1 status bar. So any clipping is bound to be inaccurate and bad.
Dwedit wrote:
Whenever I played on a certain old Mitsubishi TV, my NES always displayed the bottom 8 pixels, as well as an additional 8 pixels of vblank below the bottom. It cut a significant portion at the top, which even included the super mario bros 1 status bar.
Sounds like it was incorrectly adjusted. TVs tend to have four knobs on the inside: horizontal positioning, width, vertical positioning, and height. Your TV's vertical positioning was way off. I don't really think it's worth it to emulate TVs that are that miscalibrated, except as a special effect.
Yes, on several games, there is something visible below the 240th line of graphics (so to speak). I can see it popping up in games like Batman, where as you scroll horizontally, different colours in the NES' palette show up for 1 or 2 scanlines. This is the ATT table being (unintentionally) shown, right?
That wouldn't make sense, the PPU stops fetching data after scanline 240. It's probably the background colour influenced by the PPU address changing due to VRAM writes at the start of vblank.
Your tv somehow ignores or delays response to the NES vblank signal.
Your tv somehow ignores or delays response to the NES vblank signal.
It's not my TV that does it. All TVs/Monitors I have ever used show this.
Take a look from Brad Taylor's NES Tech doc:
I'm sure someone else can explain exactly what we see in that final "useless" scanline, but I think I remember reading someone's post somewhere that mentioned that sometimes the PPU renders the ATT table on-screen.
Anyone?
Take a look from Brad Taylor's NES Tech doc:
Quote:
21..260: after rendering 1 dummy scanline, the PPU starts to render the
actual data to be displayed on the screen. This is done for 240 scanlines,
of course.
261:after the very last rendered scanline finishes, the PPU does nothing
for 1 scanline (i.e. the programmer gets screwed out of perfectly good VINT
time). When this scanline finishes, the VINT flag is set, and the process of
drawing lines starts all over again.
actual data to be displayed on the screen. This is done for 240 scanlines,
of course.
261:after the very last rendered scanline finishes, the PPU does nothing
for 1 scanline (i.e. the programmer gets screwed out of perfectly good VINT
time). When this scanline finishes, the VINT flag is set, and the process of
drawing lines starts all over again.
I'm sure someone else can explain exactly what we see in that final "useless" scanline, but I think I remember reading someone's post somewhere that mentioned that sometimes the PPU renders the ATT table on-screen.
Anyone?
ccovell wrote:
I remember reading someone's post somewhere that mentioned that sometimes the PPU renders the ATT table on-screen.
I remember that happening when you specifically set $2006 to point to the attribute table, I don't know about the last scanline.
Did you mean Konami's Batman Returns? The bottom rendered scanline (260 for Brad Taylor) shows some garbage, and changes a bit when scrolling horizontally.
If you meant Sunsoft's Batman, what specifically is visible? Is it 1 solid colour that rapidly changes when scrolling horizontally, and stays stable when not scrolling? This would happen if the rendered pixel colour is taken from the PPU address low 5 bits.
If you meant Sunsoft's Batman, what specifically is visible? Is it 1 solid colour that rapidly changes when scrolling horizontally, and stays stable when not scrolling? This would happen if the rendered pixel colour is taken from the PPU address low 5 bits.
Chris: is this what it looked like?: batmandisco
Yes, exactly like that, but only for 1 (or 2???) scanlines.
2 scanlines, judging from video captures I've seen of other games: the 'useless' scanline (261), and the scanline just after the NES vblank signal (262, or would that be 0 for Brad Taylor? 
). What shows through is what I assumed: specifically the background colour, or ppu_address&$1F if ppu_address is $3Fxx.
). What shows through is what I assumed: specifically the background colour, or ppu_address&$1F if ppu_address is $3Fxx.