It is currently Tue Oct 16, 2018 9:06 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Jun 05, 2013 5:17 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3629
Location: Mountain View, CA
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!)


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 3:05 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1389
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.


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 4:23 pm 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
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.


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 4:59 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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.


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 6:25 pm 
Offline

Joined: Thu Mar 02, 2006 12:30 pm
Posts: 171
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.


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 6:54 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3629
Location: Mountain View, CA
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* :-)


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 7:09 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 7:19 pm 
Offline

Joined: Thu Mar 02, 2006 12:30 pm
Posts: 171
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).


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 11:19 pm 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
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.


Top
 Profile  
 
PostPosted: Thu Jun 06, 2013 11:55 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Fri Jun 07, 2013 2:50 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
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.


Top
 Profile  
 
PostPosted: Fri Jun 07, 2013 6:59 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20657
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Jun 07, 2013 8:34 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3629
Location: Mountain View, CA
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. :-)


Top
 Profile  
 
PostPosted: Sat Jun 08, 2013 12:26 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
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


Top
 Profile  
 
PostPosted: Sat Jun 08, 2013 3:51 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group