It is currently Thu Oct 19, 2017 3:12 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Aug 26, 2016 4:27 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
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.
I remember seeing this post a while back, and it felt off because I'd sworn I'd seen it in the docs somewhere, though when I looked I couldn't find it. When looking through the docs today, I stumbled upon it again.

So, to set the record straight (not that anyone probably cares), here's what the Programming Cautions chapter (page 2-24-3) has to say:
Attachment:
caution13.png
caution13.png [ 33.51 KiB | Viewed 1585 times ]

It's interesting to see the extent to which Nintendo followed this guideline within their own products, for instance Super Metroid:
Attachment:
Super_Metroid_Grapple_Beam_cropped.png
Super_Metroid_Grapple_Beam_cropped.png [ 17.67 KiB | Viewed 1585 times ]
Clearly a lot is lost if you crop out everything within two tiles of the screen edge: the minimap becomes less useful, you can no longer see all your energy tanks (most crucially, you can't tell if you have one extra energy tank left, or none at all), and so on. Yet, you can still see the most important things, like your actual energy count, which weapon you have equipped, and your ammo counts, the lack of which would make the game much more annoying to play. Whether the design of the game's HUD actually took this into account or was just a coincidence is up for debate, though.


Top
 Profile  
 
PostPosted: Fri Aug 26, 2016 5:42 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
I believe what Nintendo is referring to when they say "two characters" is called the "title safe" region. HOWEVER, a lot of games complied with what is called the "action safe" area for most, but not all things. I say "most but not all" because on later titles developed with non-CRTs in mind (given the era) they really applied both the "title safe" and "action safe" regions in the same game. Picture attached helps depict what I'm talking about.

I would say "most" games tried to apply the "action safe area", where the cut-off amount is less than the "title safe area". CRTs even in the early 90s were better than those in the mid-80s as far as being able to show reliable pixels on the left/right edges of the screen without distortion or problems, combined with the fact that TV vendors began showing more of the actual CRT, i.e. the "worrisome areas" were smaller/less and thus more of the picture was visible. (We all know that higher quality TVs and ESPECIALLY high-end CRT monitors let you configure the screen overscan region or H-size/V-size so that you could see well into overscan -- both a blessing and a curse depending on the quality of the screen and gun).

I think different SNES titles honoured this warning/concern at varying depths, i.e. some titles may have been more aggressive about the the cut-off area vs. other ones. It's neat that with emulators we can see all of the rendered area without concern of that. :-)

Sorry if my post seems vague or isn't phrased very well -- on pain killers right now for my neck.


Attachments:
File comment: Action safe vs. title safe vs. full area
example.png
example.png [ 224.03 KiB | Viewed 1561 times ]
Top
 Profile  
 
PostPosted: Fri Aug 26, 2016 6:27 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19103
Location: NE Indiana, USA (NTSC)
N's background planning sheets for the NES likewise assumed an 80% (224x192 pixels out of 280x240) title safe area. See also Overscan on the wiki.


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 8:29 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3071
Location: Nacogdoches, Texas
Overscan is one reason that I don't know why more SNES games didn't use forced blanking to upload more data to vram. The only CRT's I know of that support moving the picture are computer monitors. I suppose one thing you could do for an SNES game that uses forced blanking for uploading more data would be to be able to configure where the game screen falls on the overall screen. The TV I use is weird in that it cuts of something like 16 pixels on the bottom of the screen, but none on the top. This is really kind of a pain if I'm playing R-Type III, because I can only see the very top of the status bar but I can see black on the top of the screen.


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 9:36 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2286
It's funny because I've always thought too many SNES games used black bars. Like Street Fighter 2, it looks like it was only done just in case 2 Zangiefs were onscreen, and both of them, the background layer and the HUD happened to get updated on the same frame, even though there were ways to get around it.

As for games that used letter-boxing that actually made use of it, I can agree that there's not that many that made good use of the extra time. Also most letter-box games made it uglier by having more black on top, then on the bottom. Street Fighter 2, uses the bottom bar to update the OAM, and then waits for NMI to update the rest. It would be better to just use IRQ as NMI, and disable the NMI, so there are no interruptions.


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 12:30 pm 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
Espozo wrote:
Overscan is one reason that I don't know why more SNES games didn't use forced blanking to upload more data to vram.

Had you been born early enough to experience, and live in, the '90s as a kid, you would know that until at least 1995, state-of-the-art SNES games simply didn't need to do what you're implying (i.e., optimize their code for FMV or whatever) in order to still be great games. ;) (And by 1996, the SNES was considered pretty much dead even here in Europe, BTW.)

Then again, you're always coming across as very confident when it comes to mastering all sorts of programming tricks. So, if I may ask, where's e.g. your very own MSU1 video player showing off that you totally know what you're even talking about?

Just curious ... :lol:

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 1:12 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2286
I don't remember Espozo ever saying anything about FMV.


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 1:17 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
I never used forced blanking on anything I coded because quite literally the ramifications seemed negative to me: force blanking effectively tells the PPU to stop rendering (in turn, allowing the CPU to manipulate/access PPU RAM inside of a period where normally would result in visual corruption). The visual results of this are what exactly? I imagine a portion of the screen (where/how long/wide/etc. would vary depending on timing and length) being black? Showing the last piece of data read by the PPU (thus drawn by the electron beam) in repetition until force blanking is disabled?

Using forced blanking to "get more CPU time" only, to me, seems only to be a viable option if you're willing to give up some space at the top or bottom of the screen. I can't imagine this being a common go-to technique for SNES games (please note use of the word "common"). People then, just as now, knew how much time there's available in VBlank -- gotta make it all fit/work.


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 1:25 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
It forces the screen black. One good use of forced blanking is when you're switching scenes (e.g. loading a level). Fade the screen out, turn forced blanking on, and then you can load everything you need into VRAM and change PPU settings all in one go, without worrying about VBlank time running out and having to split things into chunks. Then turn forced blanking off again, and fade the screen back in. This was by far the most common use of it, making the entire screen blank rather than a portion of it.

Another use is for splitscreen, where you can make the middle of the screen blank for a few scanlines to give you time to update stuff for the second player, if you don't have enough time during HBlank.


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 2:04 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Hadn't thought of those use cases. Really good insights there; thanks Nicole!


Top
 Profile  
 
PostPosted: Sat Aug 27, 2016 6:32 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
Super Mario Kart is a good example of a two-player game that uses forced blank mid-screen to rearrange OAM (or so I've been told). It also trims 3 lines off the top of the screen and 5 off the bottom, for a total height of 216 lines, but I'm not sure exactly why.

Super FX games typically trim the screen a fair bit, both to ease fillrate requirements (224x192 is only 3/4 of the screen) and to cope with the bandwidth demands of heavy software rendering. Star Fox reportedly peaks at 20 fps, which is too fast for normal VBlank but works fine with a 190-line display. Even Yoshi's Island runs at 256x208 in-game.

I do wonder if Street Fighter Alpha 2 could reasonably be squeezed into 256x224 with full-scale sprites by making judicious use of double-buffering, and perhaps a built-in constant lag frame to avoid situational lag due to prediction failures (though I don't typically play fighting games on a D-pad, so maybe that's a bad idea - then again, Street Fighter V reportedly has 8 frames of input lag)... Espozo managed to jam a Zangief frame into 92 tiles, so it's not obviously impossible...


Top
 Profile  
 
PostPosted: Mon Aug 29, 2016 12:10 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1338
Force blanking to increase Vblank time is fine between scanlines. The only thing you have to notice is that sprite fetching happens during Hblank on the line before. So you don't want to have sprites on the first line after the screen is re-enabled. Trying to time your screen enable right after the visible scanline but before the sprite fetching would be too tricky and would probably fail anyway due to latches in play.

But the technique definitely works: there are commercial games that use it, like SFA2. If more games did this, then we'd have an easier time scaling games to fill widescreen monitors, too.

Toggling force blank in the middle of a scanline also works, but here you really will end up with lots of graphical artifacts as latches will stop being updated, and then not be reloaded upon re-enabling things. And trying to time this to do anything interesting would be next to impossible.


Top
 Profile  
 
PostPosted: Mon Aug 29, 2016 12:47 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19103
Location: NE Indiana, USA (NTSC)
So if you're targeting a Super NES game to NTSC TVs made since 1995, I propose these parameters:
  • Visible area: 256x176 (lines 25 through 200)
  • Title safe area: 240x160 (same size as GBA display)
  • Turn off forced blanking during hblank after line 23
  • Set nonzero brightness during hblank after line 24, or use windows to blank that line

On PAL, you'd instead use 256x208 with a safe area of 240x192.


Top
 Profile  
 
PostPosted: Mon Aug 29, 2016 1:40 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6282
Location: Seattle
Given the size of modern TVs (i.e. usually much bigger), and the low vertical resolution of the SNES, I really can't see a reason to target the full 16:9 de-windowboxing scaler video mode inside HDTVs.

On PAL NESes, however, there is a conspicuous advantage to using that mode to hide artifact collisions off the top and bottom.


Top
 Profile  
 
PostPosted: Mon Aug 29, 2016 6:50 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 784
tepples wrote:
So if you're targeting a Super NES game to NTSC TVs made since 1995, I propose these parameters:
  • Visible area: 256x176
  • Title safe area: 240x160

Why?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: HihiDanni and 5 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