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

NES vs. SNES screen resolution

NES vs. SNES screen resolution
by on (#112770)
I've got a question about the resolution of the NES vs. the resolution of the Super Nintendo:

The NES is 256 x 240 while a standard NTSC TV typically just shows 256 x 224 of the pixels. But from a pure data point of view, it's 256 x 240 and you can make the additional rows visible in an emulator.
The Super Nintendo is 256 x 224 and even in an emulator, you see just that, not 256 x 240.

So, does that mean that the Super Nintendo has a lower resolution than the NES?

And if a TV cuts off some of the rows from the NES image, wouldn't that mean that the TV cuts off rows from the Super Nintendo image as well? And since the Super Nintendo has only 224 pixel rows natively, wouldn't that mean that the Super Nintendo image as shown by an NTSC TV screen is even less than 224 rows while the same TV screen does show 224 line of the NES's 240 lines?
Re: NES vs. SNES screen resolution
by on (#112775)
The SNES have one bit somewhere that allows you to automatically remove the overscan area, and not all games use this option. Therefore games can be 256x224, 256x240, or even something else if hires or interlaced mode are considered.


Quote:
And if a TV cuts off some of the rows from the NES image, wouldn't that mean that the TV cuts off rows from the Super Nintendo image as well?

Absolutely.
Re: NES vs. SNES screen resolution
by on (#112776)
Bregalad wrote:
Quote:
And if a TV cuts off some of the rows from the NES image, wouldn't that mean that the TV cuts off rows from the Super Nintendo image as well?

Absolutely.

Sure, but it doesn't mean that if, for example, the TV cuts 16 scanlines from top and bottom of the NES' 240 scanlines, that it would cut 16 scanlines from top and bottom of SNES' 224 scanlines as well.
Re: NES vs. SNES screen resolution
by on (#112780)
JimDaBim wrote:
And if a TV cuts off some of the rows from the NES image, wouldn't that mean that the TV cuts off rows from the Super Nintendo image as well? And since the Super Nintendo has only 224 pixel rows natively, wouldn't that mean that the Super Nintendo image as shown by an NTSC TV screen is even less than 224 rows while the same TV screen does show 224 line of the NES's 240 lines?


No, because the image that a SNES sends to the TV includes all of those extra lines -- they're just empty black, and can't be used to display graphics.
Re: NES vs. SNES screen resolution
by on (#112783)
The register Bregalad is referring to is bit 2 of SETINI ($2133), where 0 = 224 vertical lines, 1 = 239 vertical lines, barring use of interlace mode (which is its own beast in itself).

No where in any of the developers manual documentations that I have does Nintendo state you should avoid using certain ranges of columns (vertical) or lines (horizontals) of pixels to deal with visual areas which may be hidden by the physical border of certain television sets. This information is considered one of those "tribal knowledge" things when working with either NTSC or PAL.

Furthermore, the SNES/SFC offers a high-resolution interlaced mode (controlled via bit 0 of INISET). The way this works depends on what video mode you're using; video modes 0-4 and 7 behave differently than modes 5 and 6 when using interlaced mode. There's too much to discuss about this mode in a post, so I'm not going to (if you want to read more about it, drop me a PM and I can give you a link to a PDF that you can enjoy sifting through). There are games which use this, usually as a "high resolution" title screen with little to no animation (example title: Yuu Yuu Hakusho Tokubetsu Hen's first couple screens when powering on the system).

Finally, there is what's called "H-Pseudo 512" mode (controlled via bit 3 of INISET), where in modes 0-4 and 7 you get visually 512 horizontal pixels of resolution, with the console itself doing a form of blending/averaging between two pixels (i.e. if normally two pixels of red (rgb 255,0,0) and black (rgb 0,0,0)) were next to one another, this mode would result visually in 3 pixels: rgb 255,0,0 / rgb 128,0,0 / rgb 0,0,0. You cannot use add/sub screen capabilities when using H-Pseudo 512. I've never seen this used, but there are probably some games that I've never played which do.

So no, the SNES/SFC does have generally higher resolution modes than the NES, but they are not commonly/consistently used throughout lots of games. They're less common given their limitations and higher complexities. Most people use 256x240 or 256x224. NTSC vs. PAL plays a role here, obviously.

Bottom line: games on the SNES/SFC tended to use all the available pixels, and DO NOT avoid use of certain areas (columns or lines) just because "someone's TV might cut it off". If someone's TV cut off some of the visual area, the owner/user was expected to adjust the H-size or V-size of their TV. Meaning: there was less concern over the "title safe" and "action safe" areas (see wikipedia for what those terms mean), and people were simply expected to adjust their TV sets.

For example on my Sony Trinitron CRT/TV, with many NES and SNES games I have difficulty seeing the top and bottom 4-5 scanlines given how the actual TV operates/behaves. The solution is for me to adjust (decrease) V-size slightly.

The thing the NES did with PPUMASK ($2011) bits 1 an 2 (show/hide the left 8 most pixels of the screen for BG and sprites, respectively) was just silly. There is nothing like that on the SNES/SFC.

P.S. -- 256x240 mode does not "show extra black" at the bottom of the screen compared to 256x224. Instead, what ends up happening is that in 256x224 VBlank lasts a bit longer (meaning with NTSC you have less VBlank time). The same applies on the NES.

P.P.S. -- I'll drop byuu a PM on here and let him know of this thread (since it's in the NESdev section not SNESdev, not sure if he visits the non-SNES sections), as he can probably add some clarification to some of what I've said.
Re: NES vs. SNES screen resolution
by on (#112789)
koitsu wrote:
No where in any of the developers manual documentations that I have does Nintendo state you should avoid using certain ranges of columns (vertical) or lines (horizontals) of pixels to deal with visual areas which may be hidden by the physical border of certain television sets.

But it's in the background planning sheets used by Nintendo during the development of Super Mario Bros. and The Legend of Zelda, which assume a title safe area of (16, 24) to (223, 215), missing 24 lines at top and bottom and 16 pixels on each side of the line.

After studying several TV sets, I'd assume a safe area that happens to be identical to the area displayed by PocketNES: (8, 16) to (223, 229), missing 16 on top, 11 on bottom, and 8 on each side. The imbalance between top and bottom appears to come from how analog TVs' vertical retrace circuits handle the slightly faster frame rate of the NES and Super NES. For the Super NES, I'd preliminarily guess 8 on top and 5 on the bottom. Digital TVs tend to be more even with what they cut off.

Quote:
Finally, there is what's called "H-Pseudo 512" mode (controlled via bit 3 of INISET), where in modes 0-4 and 7 you get visually 512 horizontal pixels of resolution, with the console itself doing a form of blending/averaging between two pixels [...] I've never seen this used, but there are probably some games that I've never played which do.

Jurassic Park and Kirby's Dream Land 3 apparently use this to enable certain blending effects that involve background + foreground + solid color.

Quote:
If someone's TV cut off some of the visual area, the owner/user was expected to adjust the H-size or V-size of their TV.

I thought only composite computer monitors, not TVs, had those knobs accessible to the user. But I do remember seeing a caution in the manual for Jeopardy! 25th Anniversary Edition about how older sets with rounded corners might cut off information.

Quote:
Meaning: there was less concern over the "title safe" and "action safe" areas (see wikipedia for what those terms mean), and people were simply expected to adjust their TV sets.

NESdev Wiki has its own article about overscan and pixel aspect ratio, including test results from actual TVs.

Quote:
The thing the NES did with PPUMASK ($2011) bits 1 an 2 (show/hide the left 8 most pixels of the screen for BG and sprites, respectively) was just silly. There is nothing like that on the SNES/SFC.

Other than the window register set, which is essentially a more general version of the same clipping functionality that's often manipulated with HDMA. Kirby Super Star uses it for the same reason as NES games: to hide artifacts of horizontal or 1-screen mirroring. F-Zero uses it for the player's shadow, and Super Mario Kart uses it for the player's position.
Re: NES vs. SNES screen resolution
by on (#112791)
koitsu wrote:
P.S. -- 256x240 mode does not "show extra black" at the bottom of the screen compared to 256x224. Instead, what ends up happening is that in 256x224 VBlank lasts a bit longer (meaning with NTSC you have less VBlank time). The same applies on the NES.


I assume you meant to to say:
Quote:
256x224 mode does not "show extra black" at the bottom


From the point of view of the TV, it does; 256x224 mode is just 256x240 mode with extra black lines at top and bottom. Yes, from the point of view of the console, you get extra vblank time, but I was talking about how things get presented on the TV.
Re: NES vs. SNES screen resolution
by on (#112800)
tepples wrote:
Quote:
If someone's TV cut off some of the visual area, the owner/user was expected to adjust the H-size or V-size of their TV.

I thought only composite computer monitors, not TVs, had those knobs accessible to the user.

Service Menu FTW.
Re: NES vs. SNES screen resolution
by on (#112801)
TVs didn't always come with instructions to access the service menu, and Google didn't exist until the Super NES era was pretty much over.
Re: NES vs. SNES screen resolution
by on (#112803)
I had at least one old beater TV (late 70s, early 80s) with manual knobs on the back for image adjustment. you could get the entire NES 240 high to show up as visible on it (but not the whole 256 wide, iirc; h-size knob covered much less ground than the v-size knob).
Re: NES vs. SNES screen resolution
by on (#112806)
koitsu wrote:
Finally, there is what's called "H-Pseudo 512" mode (controlled via bit 3 of INISET), where in modes 0-4 and 7 you get visually 512 horizontal pixels of resolution, with the console itself doing a form of blending/averaging between two pixels (i.e. if normally two pixels of red (rgb 255,0,0) and black (rgb 0,0,0)) were next to one another, this mode would result visually in 3 pixels: rgb 255,0,0 / rgb 128,0,0 / rgb 0,0,0. You cannot use add/sub screen capabilities when using H-Pseudo 512. I've never seen this used, but there are probably some games that I've never played which do.


Is this the mode that Kirby's Dreamland 3 uses for transparency effects? I bring this up because on my LCD monitor that takes S-video, the 512 columns can be very clearly differentiated and do not blend the way they would be expected to.
Re: NES vs. SNES screen resolution
by on (#112814)
mikejmoffitt wrote:
Is this the mode that Kirby's Dreamland 3 uses for transparency effects? I bring this up because on my LCD monitor that takes S-video, the 512 columns can be very clearly differentiated and do not blend the way they would be expected to.
Using composite, Svideo, or component? They really ought to blur completely using composite, and the hue (but not brightness) should blur using s-video...
Re: NES vs. SNES screen resolution
by on (#112816)
The columns are not blended by the SNES hardware itself, but rather by the display device. Using one with sufficient resolution (like an LCD) will indeed show each one individually.
Re: NES vs. SNES screen resolution
by on (#112818)
mikejmoffitt wrote:
koitsu wrote:
Finally, there is what's called "H-Pseudo 512" mode (controlled via bit 3 of INISET), where in modes 0-4 and 7 you get visually 512 horizontal pixels of resolution, with the console itself doing a form of blending/averaging between two pixels (i.e. if normally two pixels of red (rgb 255,0,0) and black (rgb 0,0,0)) were next to one another, this mode would result visually in 3 pixels: rgb 255,0,0 / rgb 128,0,0 / rgb 0,0,0. You cannot use add/sub screen capabilities when using H-Pseudo 512. I've never seen this used, but there are probably some games that I've never played which do.


Is this the mode that Kirby's Dreamland 3 uses for transparency effects? I bring this up because on my LCD monitor that takes S-video, the 512 columns can be very clearly differentiated and do not blend the way they would be expected to.

Show me a video (Youtube, etc.) of said transparency effects and I can probably tell you. The most common "transparency" used on the SNES is the screen add/sub stuff, which is separate/independent of H-Pseudo 512.
Re: NES vs. SNES screen resolution
by on (#112819)
BMF54123 wrote:
The columns are not blended by the SNES hardware itself, but rather by the display device. Using one with sufficient resolution (like an LCD) will indeed show each one individually.

Thanks for the clarification -- actual displays (meaning the technology, aside from the obvious electron gun behaviour + HBlank + VBlank) and how they work is something I do not understand. I always appreciate the insights.
Re: NES vs. SNES screen resolution
by on (#112820)
tepples wrote:
koitsu wrote:
No where in any of the developers manual documentations that I have does Nintendo state you should avoid using certain ranges of columns (vertical) or lines (horizontals) of pixels to deal with visual areas which may be hidden by the physical border of certain television sets.

But it's in the background planning sheets used by Nintendo during the development of Super Mario Bros. and The Legend of Zelda, which assume a title safe area of (16, 24) to (223, 215), missing 24 lines at top and bottom and 16 pixels on each side of the line.

No where in the SNES developers manual does Nintendo state... ... ... --no-tepples-pedantic please. :P

The rest of what you said = gotcha/understood. (And thanks for listing off some games which use said features!)
Re: NES vs. SNES screen resolution
by on (#112837)
koitsu, thread seems correct to me, so I'll just add some useless trivia instead.

SNES output is 225 or 240 lines (with line zero always being blank for sprite prefetching.) Overscan bit toggles this. Once per rendered frame, the SNES checks this setting to determine when to start drawing to the actual television, or where to seek the beam to. I am not really sure. The basic thing is ... at 225-height, the image is centered, so half of the 15 black lines are at the top, and half at the bottom. Educated guess: 7 at the top + 1 always black, and 8 at the bottom.

So if you toggled overscan on a still image every frame, you'd see the image bouncing up and down. My understanding breaks down when you cross what's observable in software into how the hardware side is operating, so I have no idea how it manages to do this in practice. But it's completely transparent to the SNES software, it still thinks that rendering begins at V=1 either way, and it ends at V=225 or V=240 based on the overscan bit.

To get really technical, my suspicion is that the actual V=1, H=0 from the SNES HVcounters is a convenient lie for the sake of software developers, and you're really already in the middle of the NTSC screen at that point. I also think that the first dot isn't rendered until around H=22 or so, which explains why Hblank lasts until H=278 instead of H=256.

So on NTSC without overscan, it fills the screen. And with overscan, it cuts off the top and bottom a bit. The inverse is true for PAL. No overscan of course shows you the black lines at the top and bottom (image centered), and with overscan the entire screen is filled.

You can also technically toggle the overscan bit mid-frame to re-enable rendering between V=225 and V=240, with mixed success. The image won't shift down, and things like sprite pre-fetching will be botched for a scanline, but things mostly work. Whether you could trick an actual display into drawing even lower than normal by enabling overscan after the frame began, I do not know. I don't have a TV with a V-adjust that will let me see that low. Would be really cute if you could end up sending caption encoded text by writing below the drawing area that way :P

Interlace mode is another setting that is cached each frame, or possibly every two frames, I'm not really sure there. The cached setting determines whether the screen is actually rendered in interlaced mode or in progressive mode. However, once again you can toggle it mid-frame, and it will affect various tile addressing behavior and such, it'll just draw it to the TV in the cached mode anyway.

The pseudo-hires and hires stuff is a bit tough to nail down in terminology. Gets back into the concept that NTSC doesn't have horizontal resolution, it's up to the display output and how fast it tries to change colors, and the TV on how quickly it reads those colors. On the SNES side, it still computes a main and sub screen pixel for every 256 dots regardless of the hires setting, it's just that regular mode always ends up with the same color in both, pseudo-hires tends to get one of each from different BGs (helps with blending), and hires tends to get two from the same BG (helps with hires.)

The most interesting property here is that you can toggle pseudo-hires and/or hires mid-scanline as well, and it works just fine. It's not outputting a pseudo-width between 256 and 512 when you do this.

So with all I understand, I take a kind of controversial view that few people like with how I personally choose to render video. First, the NTSC vs PAL cropping of overscan is due to analog properties that aren't an issue with a PC. So I show all 240 scanlines. Some games use them, some games don't. People tend to not like not being able to fill the screen 100% from top to bottom with colored lines, but oh well. Video shaders can do that anyway if it's that important. Next, because of being -able to-, even if nothing does, toggle the hires bits mid-scanline, it's better to just output at a consistent 512 pixel width. This of course would break a naive HQ2x software filter, but a smarter vector-based shader that treats the screen as having 256 "dots" in normalized space would work fine, so that's fine too. Also tends to produce a sharper image with bilinear filtering, for obvious reasons.

All in all, I'll take the SNES any day over the NES game of "how many pixels from each side do I crop to avoid showing gibberish?" :P
Practically almost warrants a per-game overscan mask database.
Re: NES vs. SNES screen resolution
by on (#112869)
byuu wrote:
Interlace mode is another setting that is cached each frame, or possibly every two frames, I'm not really sure there. The cached setting determines whether the screen is actually rendered in interlaced mode or in progressive mode. However, once again you can toggle it mid-frame, and it will affect various tile addressing behavior and such, it'll just draw it to the TV in the cached mode anyway.
In terms of the signal sent to the TV, the interlace bit only affects whether VSync ends between two scanlines or in the middle of one scanline. (This may not be entirely accurate, but the important distinction is a half-scanline difference in timing.) The TV only sees that once per scan, shortly before VBlank ends, so changing the interlace bit during rendering can't affect what the TV is doing. So, it might not be cached at all.
Re: NES vs. SNES screen resolution
by on (#112870)
koitsu wrote:
No where in any of the developers manual documentations that I have does Nintendo state you should avoid using certain ranges of columns (vertical) or lines (horizontals) of pixels to deal with visual areas which may be hidden by the physical border of certain television sets. This information is considered one of those "tribal knowledge" things when working with either NTSC or PAL.

So wait, Sega was more cautious than Nintendo here? Sega explicitly stated in documentation the need for a horizontal margin of 2 tiles and a vertical margin of 1 tile as a safe area (note that was for 224 pixels high, for 240 pixels high you'd want a vertical margin of 2 tiles).

koitsu wrote:
Show me a video (Youtube, etc.) of said transparency effects and I can probably tell you. The most common "transparency" used on the SNES is the screen add/sub stuff, which is separate/independent of H-Pseudo 512.

It's H-Psuedo 512 actually, I had checked the game before when the discussion was around, it's extremely obvious in an emulator. Mario no Super Picross does it too.
Re: NES vs. SNES screen resolution
by on (#112875)
byuu wrote:
You can also technically toggle the overscan bit mid-frame to re-enable rendering between V=225 and V=240, with mixed success. The image won't shift down, and things like sprite pre-fetching will be botched for a scanline, but things mostly work. Whether you could trick an actual display into drawing even lower than normal by enabling overscan after the frame began, I do not know. I don't have a TV with a V-adjust that will let me see that low. Would be really cute if you could end up sending caption encoded text by writing below the drawing area that way :P

That's basically the same type of technique that C64 coders use to display sprites in the vertical border (running most of the screen at 25 textrows, then setting it to 24 rows during the 25th row, will cause the VIC-II to "forget" to enable the border unit - it's really more like you basically skipped over the condition that causes the border unit to be enabled, thus it stays off and you get sprite fetches like normal as well as idle state data from the last byte in the 16KB of RAM that the VIC-II is pointed to). Of course, the C64 doesn't have 240 scanlines of addressable display without this trick, so I would imagine such a thing would be much less useful on the SNES. I doubt you could get the SNES to output captioning in this way since NTSC captions are located on line 21 of each field of a standard interlaced composite signal, at the top of the screen (unless pushing the screen down like this also caused the bottom line(s) to appear at the top after VBlank, which seems highly unlikely given that everything more or less restarts with regards to screen rendering after VBlank ends, if I understand correctly, and line 21 is technically part of VBlank at least with regards to the standards.

byuu wrote:
Interlace mode is another setting that is cached each frame, or possibly every two frames, I'm not really sure there. The cached setting determines whether the screen is actually rendered in interlaced mode or in progressive mode. However, once again you can toggle it mid-frame, and it will affect various tile addressing behavior and such, it'll just draw it to the TV in the cached mode anyway.

Quite technically, there is no real "caching" done of the interlace bit, at least based on my understanding of analog video. As others said, the only difference between a laced and nonlaced signal is that half line right before VBlank. Theoretically, it would technically be possible on the display device's end to display a half-laced, half-nonlaced image by displaying a half line somewhere in the active picture area. How the display device would handle this, I don't know (although I would wager that modern TVs that digitize and scale the image would have a hell of a time with such a signal). I think it's more likely that the SNES only evaluates the interlace mode latch at the actual point where it's time to determine whether or not to display a whole line or a half line at the bottom of the frame, so the only thing that matters is the final state of that latch after the whole frame has been output.

OT: It would be interesting if it were possible to generate a true interlaced signal from the NES by somehow ending the last pre-VBlank scanline halfway across the screen (or even somehow generating an extra half line), thus triggering interlace. I know for a fact that several retro computers and consoles that weren't designed to output interlace can do so - Atari 2600, Commodore 128, Commodore 16 (and by association +4), and the Atari 8-bit machines are the ones I know off the top of my head.
Re: NES vs. SNES screen resolution
by on (#112876)
Sik wrote:
koitsu wrote:
No where in any of the developers manual documentations that I have does Nintendo state you should avoid using certain ranges of columns (vertical) or lines (horizontals) of pixels to deal with visual areas which may be hidden by the physical border of certain television sets. This information is considered one of those "tribal knowledge" things when working with either NTSC or PAL.

So wait, Sega was more cautious than Nintendo here? Sega explicitly stated in documentation the need for a horizontal margin of 2 tiles and a vertical margin of 1 tile as a safe area (note that was for 224 pixels high, for 240 pixels high you'd want a vertical margin of 2 tiles).

In the case of the official SNES documentation, no, it's not stated anywhere. In the case of the official NES documentation, I have no idea (to date I have only seen a single page of said documentation), but the sprite-clip and bg-clip features of PPUCTRL almost certainly were documented and there was likely a reference page explaining screen layout and their effect + reasoning.

I think it's one of those "tribal knowledge" things that's also sort of assumed/implied that the programmer of the system is familiar with/aware of. It becomes fairly obvious when testing your game/code out though -- your colleague tests it out on his configuration with a different display and suddenly you're being scolded for putting important stuff in the first and last 6 to 8 scanlines on screen (or 6-8 pixels on the left and right edges). "Overscan and TVs with stupid plastic or faux wood borders!!!"

If you want, I can actually reach out to 3 or 4 friends of mine who did professional SNES development (most were at Tiburon) and ask them where/how they learned about the aforementioned. *shrug* :-)
Re: NES vs. SNES screen resolution
by on (#112877)
LocalH wrote:
byuu wrote:
Interlace mode is another setting that is cached each frame, or possibly every two frames, I'm not really sure there. The cached setting determines whether the screen is actually rendered in interlaced mode or in progressive mode. However, once again you can toggle it mid-frame, and it will affect various tile addressing behavior and such, it'll just draw it to the TV in the cached mode anyway.

Quite technically, there is no real "caching" done of the interlace bit, at least based on my understanding of analog video. As others said, the only difference between a laced and nonlaced signal is that half line right before VBlank.

I contend that there is:

Modern digital TVs have to notice whether the half-line occurred and then use that to select which field the digitized pixels go to in the frame buffer. It's "cached" for the entire field.

Consider a CRT TV connected to a SNES in interlace mode. In the middle of a frame, freeze time. At this point, the TV is either displaying an even or odd field. The individual scanlines in the video signal are identical for each field, yet each scanline is displayed at one of two possible positions. Thus there must be some state inside the TV knowing which of these two possible positions to use. It "caches" the even/oddness of a field in the circuit that slowly sweeps the beam from top to bottom, in the form of a very slight offset every other field.

Quote:
I think it's more likely that the SNES only evaluates the interlace mode latch at the actual point where it's time to determine whether or not to display a whole line or a half line at the bottom of the frame, so the only thing that matters is the final state of that latch after the whole frame has been output.

Since AFAIK that's the only place in the signal that differs, there's not much else that could be happening.

Quote:
Theoretically, it would technically be possible on the display device's end to display a half-laced, half-nonlaced image by displaying a half line somewhere in the active picture area.

I wonder whether you could use this to display even higher resolution images by having triple interlacing and beyond, using smaller fractions of a scanline to offset successive fields.
Re: NES vs. SNES screen resolution
by on (#112878)
blargg wrote:
LocalH wrote:
Quite technically, there is no real "caching" done of the interlace bit, at least based on my understanding of analog video. As others said, the only difference between a laced and nonlaced signal is that half line right before VBlank.

I contend that there is:

Modern digital TVs have to notice whether the half-line occurred and then use that to select which field the digitized pixels go to in the frame buffer. It's "cached" for the entire field.

Consider a CRT TV connected to a SNES in interlace mode. In the middle of a frame, freeze time. At this point, the TV is either displaying an even or odd field. The individual scanlines in the video signal are identical for each field, yet each scanline is displayed at one of two possible positions. Thus there must be some state inside the TV knowing which of these two possible positions to use. It "caches" the even/oddness of a field in the circuit that slowly sweeps the beam from top to bottom, in the form of a very slight offset every other field.

True in that regard, I was referring to the fact that there is likely no explicit "caching" within the device outputting the signal (in this case the SNES). Whichever way the TV implements interlacing will likely involve either an implicit or explicit caching of the state, as you mention. Also, do remember that to many modern digital sets, 240p doesn't really exist. Every flatscreen I've ever interacted with treated 240p signals as if they were 480i without exception, and so in this case it's not so much a cache as just putting the fields on the right lines in the final image (of course, this could still be considered a "cache" in that the set will need to know which field is upper, so as not to have a 50% chance of a swapped-field image).

Quote:
Quote:
Theoretically, it would technically be possible on the display device's end to display a half-laced, half-nonlaced image by displaying a half line somewhere in the active picture area.

I wonder whether you could use this to display even higher resolution images by having triple interlacing and beyond, using smaller fractions of a scanline to offset successive fields.

That's a very interesting concept, and one that I've never even considered, but now it seems so obvious. Of course, the tradeoff would be the overall "frame" rate of all fields combined, so if you split the last scanline into quarters, then you might end up with an effective 15Hz 960-line signal wrapped within 60Hz (and would have the option of 30Hz motion at 480 lines or 60Hz motion at 240 lines).
Re: NES vs. SNES screen resolution
by on (#112888)
LocalH wrote:
Theoretically, it would technically be possible on the display device's end to display a half-laced, half-nonlaced image by displaying a half line somewhere in the active picture area.
That would interrupt the HSync signal. You'd end up with something a lot like what happens when you fast-forward or rewind a VHS tape. Here's a page that explains nonstandard synchronization signals in great detail.

LocalH wrote:
That's a very interesting concept, and one that I've never even considered, but now it seems so obvious. Of course, the tradeoff would be the overall "frame" rate of all fields combined, so if you split the last scanline into quarters, then you might end up with an effective 15Hz 960-line signal wrapped within 60Hz (and would have the option of 30Hz motion at 480 lines or 60Hz motion at 240 lines).
Ignoring compatibility for a moment, that would be really interesting to see. I think it would flicker really badly if you displayed the same picture at all four offsets, though.
Re: NES vs. SNES screen resolution
by on (#112889)
Joe wrote:
Oh, that's what the equalization pulses are for!

LocalH wrote:
That's a very interesting concept, and one that I've never even considered, but now it seems so obvious. Of course, the tradeoff would be the overall "frame" rate of all fields combined, so if you split the last scanline into quarters, then you might end up with an effective 15Hz 960-line signal wrapped within 60Hz (and would have the option of 30Hz motion at 480 lines or 60Hz motion at 240 lines).
I once set up a microcontroller to drive a CRT computer monitor at 3x interlaced VGA (instead of above suggested 4x or standard 2x). It didn't work very well. Even after the 70/3 total frame rate causing horrific flicker and electron beam size blurring the successive fields, the on-screen spacing between fields wasn't uniform or a nice function of timing.
Re: NES vs. SNES screen resolution
by on (#112926)
koitsu wrote:
Sik wrote:
koitsu wrote:
No where in any of the developers manual documentations that I have does Nintendo state you should avoid using certain ranges of columns (vertical) or lines (horizontals) of pixels to deal with visual areas which may be hidden by the physical border of certain television sets. This information is considered one of those "tribal knowledge" things when working with either NTSC or PAL.

So wait, Sega was more cautious than Nintendo here? Sega explicitly stated in documentation the need for a horizontal margin of 2 tiles and a vertical margin of 1 tile as a safe area (note that was for 224 pixels high, for 240 pixels high you'd want a vertical margin of 2 tiles).

In the case of the official SNES documentation, no, it's not stated anywhere. In the case of the official NES documentation, I have no idea (to date I have only seen a single page of said documentation), but the sprite-clip and bg-clip features of PPUCTRL almost certainly were documented and there was likely a reference page explaining screen layout and their effect + reasoning.

I think it's one of those "tribal knowledge" things that's also sort of assumed/implied that the programmer of the system is familiar with/aware of. It becomes fairly obvious when testing your game/code out though -- your colleague tests it out on his configuration with a different display and suddenly you're being scolded for putting important stuff in the first and last 6 to 8 scanlines on screen (or 6-8 pixels on the left and right edges). "Overscan and TVs with stupid plastic or faux wood borders!!!"

If you want, I can actually reach out to 3 or 4 friends of mine who did professional SNES development (most were at Tiburon) and ask them where/how they learned about the aforementioned. *shrug* :-)

If it is mentioned in documentation, I don't see why it would need to consist of more than a small diagram showing NTSC safe zones and a sentence or two. It has always been mind-boggling to me that developing with safe zones on the TV in mind has received so much discussion and write-ups. You can wrap it up as "consider that a few tiles on each edge may be cut off because some TVs are different". Beyond that the developer probably has the smarts to experiment on different TVs and keep it in mind... it seems that for Nintendo to tell people which columns are allowed for important data is going into necessary levels of detail.
Re: NES vs. SNES screen resolution
by on (#112934)
It is mentioned in documentation, though it might not be NES-era documentation. Nintendo's lot check guidelines for the GameCube, Sony's technical requirements checklist for the PlayStation 2, and what Microsoft called the equivalent on the original Xbox all had specific safe area guidelines. I seem to remember that Xbox games were required to keep status bars and the like at least 7.5% away from an edge. This implies a title safe area of 85% of the width and 85% of the height of the screen. I have noticed that one of the Call of Duty games my cousin plays on his Xbox 360 has a "safe area" option in the menu that allows moving the HUD closer to or farther from the corners. But a user-defined safe area is really only practical on platforms with an expectation of save capability and no rigid tile grid, such as Dreamcast or anything newer. Particularly on a tile-based system, where the relationship between game world distances and picture distances is constant, avoiding the game design flaw of blind leaps requires at least a minimum safe area so that the developer knows how far in front of the (centered) player character the player can see.

If you want your NES or Super NES game to be widescreen friendly, I'd recommend a 30x20 tile title safe area. Keep important things 1 tile away from the left and right and 5 tiles (240 line mode) or 4 tiles (224 line mode) from the top and bottom. Umihara Kawase was way ahead of its time in this respect.
Re: NES vs. SNES screen resolution
by on (#112938)
Are we all talking past one another / not actually reading what each other write?

* No where in any of the developers manual documentations that I have does Nintendo state you should avoid using certain ranges of ... -- (vague statement by me, I should have been specific that I was referring to SNES documentation)
* But it's in the background planning sheets used by Nintendo during the development of {list of NES games} ... -- (NES docs != SNES docs)
* No where in the SNES developers manual does Nintendo state ... -- (I clarify I'm talking about SNES docs only)
* So wait, Sega was more cautious than Nintendo here? Sega explicitly stated in documentation ... -- (Sega != SNES/Nintendo)
* In the case of the official SNES documentation, no, it's not stated anywhere. -- (again, talking about the SNES docs)
* If it is mentioned in documentation, I don't see why ... -- (I've said multiple times now it isn't mentioned in the SNES docs)
* It is mentioned in documentation, though it might not be NES-era documentation. -- (no it isn't mentioned in the SNES docs, and SNES docs == "not NES-era docs")

Please do not make me stab you people. :-)
Re: NES vs. SNES screen resolution
by on (#112946)
koitsu wrote:
Are we all talking past one another / not actually reading what each other write?
* If it is mentioned in documentation, I don't see why ... -- (I've said multiple times now it isn't mentioned in the SNES docs)


I'm aware; I mentioned this to cover the possibility that the NES documentation may make mention of it, and was saying that even if it *did* appear there it is unlikely it received much documentation at all, for the same reasons they did not feel the need to make a big deal of it in SNES documentation. It was a response to "In the case of the official NES documentation, I have no idea (to date I have only seen a single page of said documentation)".

tepples wrote:
Keep important things 1 tile away from the left and right and 5 tiles (240 line mode) or 4 tiles (224 line mode) from the top and bottom. Umihara Kawase was way ahead of its time in this respect.


I'm assuming you meant to say top and bottom in both cases, not left and right.

Either way, I think by making games "widescreen friendly" all this does is chop off perfectly usable area on what is an already strikingly low-resolution system. If anything, it encourages people to use that atrocious "fit" feature that cuts off so much information to fill the screen. I guess I don't think it's good to encourage such a thing; the people who would care / notice have more than likely either configured their television set to appropriately show a 4:3 image, or are playing their system on a television the system is designed for (like a 4:3 CRT television or monitor).

If we make games just for 16:9 cropped setups, we're left with a bunch of games with awkwardly wasted space or weird HUD placements. Yeah, I'm looking at you, Umihara Kawase. I don't think of it as ahead of its time but more annoying and stupid for everyone who isn't playing their SNES on a setup that is flat-out wrong and extra-blocky with every other game.

If it's "fixed" with an option to move the HUD to appropriate spots, then is such an interference really the best solution? If we're going to go to such an effort, wouldn't it be better to just have the game tell the player "Hey nutsquad! Put your television on 4:3 mode and buy yourself an S-video cable if you don't have one for your SNES!". Everybody wins, and composite dies just a little more!

byuu wrote:
So with all I understand, I take a kind of controversial view that few people like with how I personally choose to render video. First, the NTSC vs PAL cropping of overscan is due to analog properties that aren't an issue with a PC. So I show all 240 scanlines. Some games use them, some games don't. People tend to not like not being able to fill the screen 100% from top to bottom with colored lines, but oh well. Video shaders can do that anyway if it's that important. Next, because of being -able to-, even if nothing does, toggle the hires bits mid-scanline, it's better to just output at a consistent 512 pixel width. This of course would break a naive HQ2x software filter, but a smarter vector-based shader that treats the screen as having 256 "dots" in normalized space would work fine, so that's fine too. Also tends to produce a sharper image with bilinear filtering, for obvious reasons.


Controversial or not, this is my favorite approach and you have my applause. I especially like the by-default 2x prescale you've applied that makes even the cheapest bilinear filtering preserve sharpness much more.
Plus...
Quote:
This of course would break a naive HQ2x software filter

AWESOME
Re: NES vs. SNES screen resolution
by on (#112948)
mikejmoffitt wrote:
You can wrap it up as "consider that a few tiles on each edge may be cut off because some TVs are different".

That's exactly what Sega did:
Quote:
For important indications such as the score, there shall be a two cell margin on the right and left side and one cell margin on the top and the bottom of the screen (some monitors do not show these areas well). Do not put important score, text or time information in the top, bottom, leftmost or rightmost row or columns.

But yes, this was considered a requirement for approving the game. I'm honestly surprised Nintendo didn't put that in their list, given how they were quite strict with things like "sound must not have even the most minimal clipping at all" (despite the fact clipping must be extremely high to be noticeable - the end result is that many SNES games sound way too quiet)

If you ask me, my experience has been the leftmost and rightmost columns being hidden (i.e. one tile column being cut) with the top and bottom being underscanned. That's a height of 224 though, 240 does indeed overscan a bit, but the top and bottom rows aren't obscured completely (this also means that any two-way scrolling NES game with vertical mirroring will fail miserably at hiding the scrolling glitches).

tepples wrote:
Umihara Kawase was way ahead of its time in this respect.

Except because gameplay could happen above and below the HUD. Also don't forget that now we have widescreen monitors that are wider than 2:1, and I doubt it will take long before TVs adopt that (seriously, why that wide?!).

And I don't get why the heck people think that trimming vertical resolution is widescreen. Widescreen is supposed to show more, not less! Besides trimming anything is a bad idea in a game. Just use "fit" mode and cope with the borders. If you don't want the borders because a static color can damage your screen then consider not displaying anything 4:3 on that screen in the first place.
Re: NES vs. SNES screen resolution
by on (#113400)
Is there any way of getting sprites to display at 512x448? I can only find information on hi-res background layers.
Re: NES vs. SNES screen resolution
by on (#113406)
Pretty sure that I remember reading somewhere that it doesn't work on sprites but I could be wrong. Did you check the official documentation?
Re: NES vs. SNES screen resolution
by on (#113407)
H-Mode (in modes 5 and 6) will do 512 pixels of resolution horizontally, but does not affect sprites/OBJ. Sprites are still limited to their existing sizes (from 8x8 up to 64x64, depending on what OBJ mode (small/large) you choose).

TL;DR -- Stop complaining, work with what you've got. Spoiled. :P
Re: NES vs. SNES screen resolution
by on (#113426)
That's probably one of the reasons hi-res mode wasn't used much. lo-res sprites on a hi-res background would stick out like a sore thumb.
Re: NES vs. SNES screen resolution
by on (#113429)
RPM racing was probably the only game to exclusively use hi-res mode, and it looked pretty awful in terms of frame rate and graphics quality.
Re: NES vs. SNES screen resolution
by on (#113432)
psycopathicteen wrote:
That's probably one of the reasons hi-res mode wasn't used much. lo-res sprites on a hi-res background would stick out like a sore thumb.

It may be one of the reasons, with the others (and IMO, more prominent) being that modes 5 and 6 only support 2 and 1 backgrounds, respectively. Most games used mode 1, and made heavy use of its 3 simultaneous backgrounds. I can't tell you how much of a blessing that is.

So in summary, the high-resolution modes are kind of a gimmick of sorts, but they work well for things like showing a single screen/picture or possibly some very basic form of high-resolution animation. Nintendo could have released the console with just modes 0-4 and 7 and it would have had the same quality titles. I'd even stretch that to say modes 0-3 and 7, although possibly mode 4 was used in games for vertical split-screen effects (I never did play around with the Offset Change/Address stuff).

This is all after-the-fact anyway.
Re: NES vs. SNES screen resolution
by on (#113434)
Mode 1 and 7 are the only really widely used ones really. Mode 2 and 0 are used sparsely when vertical split is needed and 4 backgrounds are needed respectively, but that's very rare.

I think the big reason modes 5 and 6 are so much underused is the fact tiles takes two times the normal size, so you get half the tiles for a constant VRAM usage. Also drawing with non square pixels is diffifcult if you don't have specific tools for this (I mean significantly non square, nobody minds an aspect ratio of 1.1, but 0.55 is a problem).
Re: NES vs. SNES screen resolution
by on (#113438)
koitsu wrote:
So in summary, the high-resolution modes are kind of a gimmick of sorts, but they work well for things like showing a single screen/picture or possibly some very basic form of high-resolution animation.

That or text. The ideographic characters used to write Japanese have a lot more detail than the alphabetic characters used to write the languages of regions where the console was called "Super NES". Even for Latin text, I seem to remember some RPGs using hi-res for more clarity. And for text, especially thin or italic text, you want a tall-and-skinny pixel aspect ratio like the 4:7 of Super NES hires mode. Look at 80-column text on a CGA or Apple II, which output a signal with 3:7 PAR.

Quote:
Nintendo could have released the console with just modes 0-4 and 7 and it would have had the same quality titles. I'd even stretch that to say modes 0-3 and 7, although possibly mode 4 was used in games for vertical split-screen effects (I never did play around with the Offset Change/Address stuff).

What mode does Panel de Pon use?
Re: NES vs. SNES screen resolution
by on (#113468)
tepples wrote:
What mode does Panel de Pon use?

Let's find out using SNES9x's debug version. You can get the info using the "What's Used" button (look for "Screen mode:").

"Nintendo Presents" title screen + text = mode 1
Main title screen ("Push any key!") = mode 1
Game selection screen = mode 1
Actual game itself = mode 2
Re: NES vs. SNES screen resolution
by on (#113470)
Meanwhile, the GBA version of Panel De Pon simply used sprites.
Re: NES vs. SNES screen resolution
by on (#113730)
koitsu wrote:
So in summary, the high-resolution modes are kind of a gimmick of sorts.


Kind of like how 64x64 sprites on the SNES were a gimmick.
Re: NES vs. SNES screen resolution
by on (#113740)
Quote:
Kind of like how 64x64 sprites on the SNES were a gimmick.

For actual sprites, yes but to simulate a BG layer when using mode 7 it can be practical.
Re: NES vs. SNES screen resolution
by on (#113743)
Bregalad wrote:
Quote:
Kind of like how 64x64 sprites on the SNES were a gimmick.

For actual sprites, yes but to simulate a BG layer when using mode 7 it can be practical.


Still wasteful/gimmick. You definitely have enough entries in the sprite table for doing fake scroll layers with smaller sizes. Plus, smaller segments means better optimization in vram for metasprite combinations. PC-Engine has 32x64 sprite size and some game use it, but the games that do have very lazy/unoptimized sprite setups - resulting in unnecessary flicker.

64x64 size would be nice *if* the sprite pixel scanline limit was much larger *and* you weren't limited to just two sprite sizes per frame (SNES). Otherwise, metasprite some 32x32's in place of.
Re: NES vs. SNES screen resolution
by on (#113759)
I wonder if any game actually used 64x64 sprites. Final Fight?
Re: NES vs. SNES screen resolution
by on (#113806)
I highly doubt Final Fight would use it. Infact Final Fight probably uses 8x8 and 16x16. I would doubt that it would use 32x32.
Re: NES vs. SNES screen resolution
by on (#113816)
64x64 sprites are used in Chono Trigger during the time travel effect. They are used to "simulate" a BG which is transparent over the mode 7 BG.

Final Fight 1 uses 8x8 and 16x16 sprites, while 2 and 3 uses 16x16 and 32x32 (during gameplay at least, I don't know if they use 64x64 elsewhere).
Re: NES vs. SNES screen resolution
by on (#128222)
I'm sorry to necrobump this one, but I was aking myself :

Which SNES games uses higher resolution than 256x240 ?

I already know about Romanging SaGa3, Secret of Mana, Seiken Densetsu 3 and Rudra no Hiho who use a horizontal resolution of 512 for some of their parts (menus, and text boxes in the latter 2).

However I don't know if any other games uses a horizontal resolution of 512, and if any game uses interlacing to get a pseudo-vertical resolution of 480.
Re: NES vs. SNES screen resolution
by on (#128223)
Kirby's Dreamland 3 uses 512px width to allow for transparency effects with vertical striping. You can kind of see it with the foreground green things here:

Image
Re: NES vs. SNES screen resolution
by on (#128224)
Mmh, so this is the infamous "pseudo-512H" mode in action ?
Why use this instead of the real transparency that is also supported by the SNES ? The only reason I'd see this used instead is that it simplifies the sprite layering, but I can't think of any other advantages. Besides, the result is likely to look worse than real transparency.
Re: NES vs. SNES screen resolution
by on (#128225)
Bregalad wrote:
Mmh, so this is the infamous "pseudo-512H" mode in action ?
Why use this instead of the real transparency that is also supported by the SNES ?

It lets the game blend three things at once, namely the backdrop, the first layer, and the second layer, as seen in the tidbits shown when Jurassic Park is paused.

I think the only game that actually uses 512x448 is RPM Racing.
Re: NES vs. SNES screen resolution
by on (#128228)
Oh thank you for telling me that.

And I don't understand what Jurassic Park is trying to do. Seems it enables the pseudo-512H mode, but with the same data for both main screen and subscreen, so this would have no effect ?
Pausing the screen just makes it darker, I guess this is done by darkening the palette as a whole, and I don't think the pseudo-512H mode has anything to do with that, especially considering it's also enable when the game is not paused.

I definitely don't think you can ever blend 3 things at once on the SNES, with both real transparency and pseudo-512H mode, they are working by blending main screen and sub-screen, so in both case you can only blend 2 layers at once. The only way to blend more is to simulate it by a trick without using hardware transparency.

Also it's quite funny, the last 3 generations of consoles before HDTVs became common all allow interlacing, but the SNES hardly ever saw it used, the PS1 saw about half of it's game using it, and the PS2 saw most of it's games using it. Isn't this a bit funny ? I guess the only reason for these choice is VRAM usage, as VRAM quantity in the console went up.

EDIT : The only use of pesudo-H512 mode I can see is that it allows to mix a (pseudo) transparency effect and a real high resolution graphic on the same scanline (and on the same frame without using HDMA/IRQ tricks). Like you could have a textbox not taking all the screen with high resolution text in it (done by interleaving pixels on purpose between main and sub-screen using 2 different BGs), and having a pseudo-transparency effect on the playfield outside of the text box (using the 2 same BGs).
Re: NES vs. SNES screen resolution
by on (#128232)
Bregalad wrote:
And I don't understand what Jurassic Park is trying to do. Seems it enables the pseudo-512H mode, but with the same data for both main screen and subscreen, so this would have no effect ?
Pausing the screen just makes it darker

Did you try waiting a minute with it paused?

Quote:
Also it's quite funny, the last 3 generations of consoles before HDTVs became common all allow interlacing, but the SNES hardly ever saw it used, the PS1 saw about half of it's game using it, and the PS2 saw most of it's games using it. Isn't this a bit funny ? I guess the only reason for these choice is VRAM usage, as VRAM quantity in the console went up.

VRAM was a large part of it why effectively all Super NES and Genesis games and most Nintendo 64 games were low definition. Fill rate was another, as filling 448 lines of pixels takes twice as long as filling 224 lines of pixels unless your engine is already rock-solid 60 fps like that of Tobal No. 1 and Ehrgeiz.
Re: NES vs. SNES screen resolution
by on (#128249)
Bregalad wrote:
Also it's quite funny, the last 3 generations of consoles before HDTVs became common all allow interlacing, but the SNES hardly ever saw it used, the PS1 saw about half of it's game using it, and the PS2 saw most of it's games using it. Isn't this a bit funny ? I guess the only reason for these choice is VRAM usage, as VRAM quantity in the console went up.


The other reason is that interlacing looks terrible for anything rendering at >30fps, since only the even or odd lines of the rendered frame are updated, either in the display's image buffer (modern displays that sample frames for analogue input) or in image persistence as far as the eye can see (CRT displays, anything that implements interlacing the way it was designed). Even then I'd argue it looks terrible as on a CRT it'll be flickery, and on a modern display it's hard to disable the image processing that makes interlaced content look... shitty? Not really sure how to word it.
Re: NES vs. SNES screen resolution
by on (#128263)
SNES and PS1 games definitely weren't designed to look good on modern LCD screens as those definitely didn't exist (or weren't affordable enough) back when those consoles were mainstream.
When PS2 came out LCD screens was still a novelty/niche but they became very common toward the end of the console's life. Yet, more PS2 games use interlacing than anything else.

Interlacing looks bad on PAL because it flickers too slowly (25 Hz), but on NTSC I think it should look better (30Hz) and most developers only cared about NTSC during the development of their games.

The fact that some cheap modern TVs does not de-interlace properly has nothing to do with the fact old games didn't use it. There exists method to deinterlace properly, but those are complicated and computationally expensive (some may also be patented). Mostly, you have to detect movement on the screen and act differently if there is movement (update all pixels at 50/60Hz) or if there is no/few movement (update odd/even rows separately when corresponding frames are sent). I did a work of this during my studies so I sort of know what I'm talking about (although I don't know what is implemented in modern LCD TVs, but I bet you see all sort of de-interlacing techniques depending on the brand, form pure cheap crap to the top high quality algorithms).

Quote:
Did you try waiting a minute with it paused?

Yeah, some instructions appear on the screen, but I don't see how this makes it "blend 3 things together", it's just another layer on the top of the normal playfield layers, no transparency at all.

PS : Am I correct by assuming the following video modes "exists" (i.e. makes sense) on the SNES :

Code:
*** Progressive video "modes" ***

 256x240,  256x224 (modes 0-4, 7) => the most common one, everything is normal resolution
 512x240,  512x224 (modes 5,6)    => high H-res BGs at the cost of having no inter-BG transparency, sprites are normal res
p512x240, p512x224 (modes 0-4, 7) => using pseudo-512 H-res BG, resolution is increased "by software"

*** Interlaced video "modes" ***

 256x480,  256x448 (modes 0-4, 7) => BG V-res is increased in software by changing the tilemap every frame, "by software"
                                     Tiles should be interleaved by hand or by HDMA V-scroll updates every line. Sprites are normal res
 256x480,  256x448 (modes 0-4, 7) => Same as above, but sprites have increased V-res as well
 256x480,  256x448 (modes 0-4, 7) => BGs not affected, but the sprites have increased V-res (but normal H-res).
                                     Vertical BG scrolling could look jerky
 512x480,  512x448 (modes 5-6)    => all is done by hardware, sprites are normal res
 512x480,  512x448 (modes 5-6)    => all is done by hardware, sprites are high V-res, but still normal H res
p512x480, p512x448 (modes 0-4, 7) => BGs have pseudo-512 H-res, vertical resolution increased in software, sprites are normal-res
p512x480, p512x448 (modes 0-4, 7) => Same as above, but sprites have increased V-res as well
p512x480, p512x448 (modes 0-4, 7) => BGss have pseudo-512 H-res, normal V-res, but sprites have increased V-res (but normal H res).
                                     Vertical BG scrolling could look jerky


PS2 : Apparently some sources says pseudo-512 is used to "smooth" the screen, while Anomie says it just alternates main and sub screen pixels.
In fact I think I sort of understood, "smoothing" the screen is only one of the possible applications. If you enable colour averaging (add and half) as a normal transparency, and the main and sub screen are the same, this will not affect main screen pixels (as the average between 2 identical values is the value itself), and subscreen pixels will be averaged with the neighbour main screen pixel, resulting in a smoothing of the screen.
If, instead, a colour constant transparency is used instead, it will work like normal, and if main and sub-screen are not the same, it results in what Kirby's game does, i.e. a "software" high resolution.

I should definitely test that on hardware and improve my SNES transparency FAQ to explain this stuff.
Re: NES vs. SNES screen resolution
by on (#128464)
I'm trying to think of an acceptable way of programming software hi-res sprites on the SNES. 4bpp is more colorful than 2bpp, but it's also more taxing on the cpu and dma. We can probably speed up code by not letting sprites overlap, and hide color limitations with attribute clashing.
Re: NES vs. SNES screen resolution
by on (#128778)
The most efficient way of doing hires sprites would probably be to draw sprites to 4 1-bit buffers and then convert the buffer into tile patterns with all the blank tiles removed. The biggest issue is weather or not converting will be fast enough.

edit: Nevermind, there's not enough RAM anyway. Maybe draw the shifted sprites to a small "sprite buffer", and then write the tiles directly to a pattern table buffer, without any full screen buffer.
Re: NES vs. SNES screen resolution
by on (#227186)
Original Post:
JimDaBim wrote:
I've got a question about the resolution of the NES vs. the resolution of the Super Nintendo:

The NES is 256 x 240 while a standard NTSC TV typically just shows 256 x 224 of the pixels. But from a pure data point of view, it's 256 x 240 and you can make the additional rows visible in an emulator.
The Super Nintendo is 256 x 224 and even in an emulator, you see just that, not 256 x 240.

So, does that mean that the Super Nintendo has a lower resolution than the NES?

And if a TV cuts off some of the rows from the NES image, wouldn't that mean that the TV cuts off rows from the Super Nintendo image as well? And since the Super Nintendo has only 224 pixel rows natively, wouldn't that mean that the Super Nintendo image as shown by an NTSC TV screen is even less than 224 rows while the same TV screen does show 224 line of the NES's 240 lines?
Hi, my name is Josh and I've been playing video games since 1983 when I was 7 years old. This was the year I got my Atari 5200 (actually I played arcade games before that). I arrived here as the result of a google search. I was searching for information about the resolution of the Nes and the Snes. I had assumed that the Nes must have lower resolution than the Snes because Snes games appear to be more finely detailed. I found out that I was wrong. So my question is: Why do the 16 bit systems graphics appear more detailed than the 8 bit systems?

Thank you and have a good day. :)
Re: NES vs. SNES screen resolution
by on (#227188)
Well, the easy answer is: More colors? :)
Re: NES vs. SNES screen resolution
by on (#227212)
Also, more/larger on-screen sprites at the same time.
Re: NES vs. SNES screen resolution
by on (#227220)
In particular, more colors are useful for antialiasing, which helps to convince the brain that there are more possible positions for edges than there are.