Target width for widescreen patches?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Target width for widescreen patches?

Post by koitsu »

byuu wrote:If the game scrolls horizontally, then it's using a 512-width or higher tilemap, and can potentially be hacked to support widescreen.
This is also inaccurate/misleading. There are commercial single-screen games which scroll horizontally; happy to mention some, but my point is the variance is massive and there's zero guarantee this will work on the majority of games.
byuu wrote:
This is entirely per-game.
I said as much.
The OP did not. See Item #0 in my initial reply. (This is a behaviour of users in general I am growing tired of in general. I see it on Discord as well, people talking about subjects out of no where as if the readers are mind-linked. It's a weird social phenomenon that I should ask sociologists and psychologists about.) I had no idea ANY information was on your website about this subject until you linked it, so thank you for that. That part about games needing to be reprogrammed/reengineered should be in a font size akin to the size of Texas. All that was stated originally was "toying around with Derkoun's fork", which to me isn't the same as "go see byuu's website" (and none of this is your fault, BTW).
AxlRocks
Posts: 4
Joined: Mon Apr 01, 2019 2:34 pm

Re: Target width for widescreen patches?

Post by AxlRocks »

lidnariq wrote:
AxlRocks wrote:I'll admit I am biased 100% towards square pixels, because I think it's far too inconsistent between what games actually have content made with 4:3 in mind, let alone all their content, but just my two cents.
US SNES pixels are always 8:7 PAR (unless they're 4:7, hush you pedant). That things were not redrawn for PAL is not an argument that PAR can be ignored, or at least not an argument that pixels can be made narrower.

SNES pixels are also never nearest neighbor horizontally. SDTV just doesn't have enough bandwidth. So optimizing for an integer scale ratio horizontally is doubly inaccurate.

The smaller the amount of faked overscan, the easier the ROM hacker's task will be. There's good reasons to pick 336x224 with an 8:7 PAR.



The alternative argument is that the amount of achievable fake overscan will depend on the game, so let the ROM hack choose its output width.
To be frank, I know exactly what you're saying, but I'll keep using 1:1 PAR for everything because I didn't care about it while playing on hardware and an SDTV 20 years ago and didn't miss it at all when I switched to emulation, don't now, and don't think I ever will. Simply because my view is that if a majority of games don't properly support it, it's just another thing to worry about instead of actually playing the games. I won't even always see a benefit where I can say "Finally, this thing is a proper circle." Instead, half the time I'll be saying, "this thing that in 3D games later in the series is a sphere ("ackchyually, on the N64 it was more like a 16 sided die due to the low poly limits"), was drawn as a sphere in the concept art and manual, and is called "orb/ball/sphere" in the game is instead some oblong egg/bean shape."

You're RIGHT, I wasn't stating that those aspect ratios are somehow incorrect. It was just my preference and an idea for compromise in regards to aspect ratios. I don't even really care if there's a target resolution everyone uses. Just wideRscreen would be cool by me. Heck, maybe it would be best to just throw the idea of a target size out, render the entire length when/if possible, and let people go from there with how they stretch (or don't) it to compensate for PAR.

Not trying to come off as argumentative or mean any offense, I just don't see the point myself but I respect that you would prefer it and understand why. But I don't think even a majority of people who would be interested in widescreen mode (as in, non purists) would notice aspect ratio correction, or the lack thereof. I think they might even be more likely to say "this is kind of wider... but doesn't feel like real widescreen" if there's only 40 more pixels on each side. EDIT: And of course, it does all depend on the technical details of each game etc, so yeah, who knows if a target resolution is even feasible right now.
Last edited by AxlRocks on Sat Aug 17, 2019 11:08 pm, edited 1 time in total.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Target width for widescreen patches?

Post by lidnariq »

AxlRocks wrote:I think they might even be more likely to say "this is kind of wider... but doesn't feel like real widescreen" if there's only 40 more pixels on each side.
I mean, 4:3 to 16:9 is multiplying everything by 4/3. 256/3 = 85 pixels. Sure, if you don't preserve the PAR it's now 14:9, but that's still going to be perceptibly wider than 12:9.

In contrast, the screenshots in the first post are an astounding 2:1 DAR (there's 30 pixels of black letterboxing). Crop it down to 400:224 (16:9 DAR 1:1PAR) and it's still good. Crop it down to 344:224 (15.8:9 DAR w/ 8:7PAR, nearest neighbor scaling vertical, linear horizontal) and personally I think it still look nice.

Alternatively, just start with a PAL SNES, because its stupid wide pixels means it's already pre-baked 3:2 widescreen :P

But more seriously, the more I think about this, the more I think this is something that should be decided on a hack-by-hack basis. It'd be a shame to discover that some games just can't get the desired "full" width, whatever that is.

Maybe even should be something dynamically configured at runtime by the hack, allowing widescreen in scenes where it works but dynamically restoring pillarboxing when it doesn't.
User avatar
FitzRoy
Posts: 144
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Target width for widescreen patches?

Post by FitzRoy »

koitsu wrote:The OP did not. See Item #0 in my initial reply. (This is a behaviour of users in general I am growing tired of in general. I see it on Discord as well, people talking about subjects out of no where as if the readers are mind-linked. It's a weird social phenomenon that I should ask sociologists and psychologists about.) I had no idea ANY information was on your website about this subject until you linked it, so thank you for that. That part about games needing to be reprogrammed/reengineered should be in a font size akin to the size of Texas. All that was stated originally was "toying around with Derkoun's fork", which to me isn't the same as "go see byuu's website" (and none of this is your fault, BTW).
So I mistakenly assumed that people here have been on reddit or seen at least 1 news item elsewhere regarding this. I did say "widescreen patches" in the title, as in more than one? Does that not imply per-game patchwork? Why is saying "Derkoun's fork" unacceptably cryptic? Can you not google it?
lidnariq wrote:In contrast, the screenshots in the first post are an astounding 2:1 DAR (there's 30 pixels of black letterboxing).
I wouldn't call 18:9 over 16:9 an "astounding" difference. 16:9 is a bigger jump over 12:9(4:3).
lidnariq wrote:Crop it down to 400:224 (16:9 DAR 1:1PAR) and it's still good. Crop it down to 344:224 (15.8:9 DAR w/ 8:7PAR, nearest neighbor scaling vertical, linear horizontal) and personally I think it still look nice.
Everything looks nice in windowed. Does it look good in fullscreen? Monitors and tvs are generally 1920. 1440p monitors are dying out in favor of 3840. 400 and 344 aren't multiples of anything commonly sold.

Below is a gif at 1920x1080 showing 480 vs 398. View it FULLscreen and see how big and warped those pixels get at an astounding 4.8 scale factor.
lidnariq wrote:But more seriously, the more I think about this, the more I think this is something that should be decided on a hack-by-hack basis. It'd be a shame to discover that some games just can't get the desired "full" width, whatever that is.
That sounds terrible, we need to push for a standard as these patches are hard to make. The option should lead to consistent results and be as simple as checking a box. We should push for 480 or even 640 and then give zoomcrop options to effectively achieve narrower outputs. If you undercut yourself, you eliminate the possibility of running in 480, which has major benefits that I am trying to point out.
Attachments
480v398fullscreen.gif
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Target width for widescreen patches?

Post by Near »

koitsu wrote:There are commercial single-screen games which scroll horizontally; happy to mention some, but my point is the variance is massive and there's zero guarantee this will work on the majority of games.
On the SNES? Some may well exist, but I would be very surprised if it were more than a tiny fraction.

If your resolution is 256xHeight, and you have a 256xHeight tilemap, you're gonna see the other side of the screen as you scroll unless you window off at least one tile row on each side first.
User avatar
FitzRoy
Posts: 144
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Target width for widescreen patches?

Post by FitzRoy »

Chrono's pupils noticeably different widths at 398 fullscreen, depending on where you're standing. Kinda looks like Dopefish.

Image

There's something visually aggravating about one of these Super Castlevania meters...

Image

Any of this hitting home yet?
Screwtape
Posts: 8
Joined: Wed Jul 10, 2019 11:34 pm

Re: Target width for widescreen patches?

Post by Screwtape »

The historically accurate way to render SNES output is with a 16-scanline overscan area (i.e. slightly letter-boxed) and aspect-corrected. While this was perfectly natural on the CRTs of the time, it doesn't play quite as well with modern displays for a few reasons:

- Modern displays are 16:9 and the SNES is designed for 4:3, so you're going to get pillarboxing (or window-boxing, if you count the overscan area)
- The SNES vertical resolution does not divide evenly into 1080p (whether or not you include the overscan area), so the user has to choose between uneven vertical scaling or extreme window-boxing
- Modern displays all have 1:1 PAR, so the user has to choose between uneven horizontal scaling or a horizontally-squished display

Some people are OK with uneven scaling (because they use fancy upscaling like CRT emulation, the Pixellate shader or just bilinear filtering), so they only have to contend with the natural pillarboxing. These people would expect a "widescreen patch" to render a ~373×240 image, aspect-corrected to ~426×240, and scaled up to ~1920×1080.

Some people hate uneven scaling with a passion, so they use integer scaling and disable aspect correction, and end up in "extreme windowboxing" mode. These people would expect a "widescreen patch" to render a 480x240 image, scaled up to 1920x960 (significant letterboxing)

If "uneven OK" people get a widescreen patch designed for "uneven BAD" people, they're likely to be annoyed at the amount of letterboxing. After all, regular SNES games fill the full height of their monitor, and a widescreen patch should only add stuff to the sides, not the top and bottom.

If "uneven BAD" people get a widescreen patch designed for "uneven OK" people, they're likely to be annoyed at the amount of pillarboxing. After all, there's so much space to the left and right of a regular SNES game, why not fill it up?

I don't think it's possible to make a single option that pleases everybody, and a compromise is likely to annoy everybody.

However, this all might be moot. As lidnariq says, every game's "widescreenability" is going to be different, so the "widescreen API" emulators provide will probably need "left margin" and "right margin" registers so different games can use different values, or even so the same game can use different values for menus/overworld/bonus stages/etc.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Target width for widescreen patches?

Post by lidnariq »

FitzRoy wrote:Any of this hitting home yet?
I'm sorry, I heard a lot of words saying "don't use pure nearest-neighbor scaling with noninteger scale ratios". So don't do that. That's not a constraint, just you picking an arbitrary rationalization to justify a width of 480.

I find your opinion about Chrono's sprite art unpersuasive.
FitzRoy wrote:[configurable] sounds terrible, we need to push for a standard as these patches are hard to make.
And by not allowing it to be configured depending on what the game is doing, you instead impose a limit that will make it even harder or impossible.
The option should lead to consistent results and be as simple as checking a box. We should push for 480 or even 640 and then give zoomcrop options to effectively achieve narrower outputs.
640 is right out; the sprite data structure imposes an upper bound of 504x248, and depending on specific sprite usage, may impose an upper bound as low as 448x192.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Target width for widescreen patches?

Post by Oziphantom »

my 2 cents...

It would be far easier to make external patches that run in the emulator, ala HD mods for NES games to do this than it would be to modify the ROMs. Tile formats are fairly standard and working out the tile format and drawing system for popular game X has probably already been done. Making some external code, Lua if one must, that looks up the games data and then calls emulator functions to "overdraw" here there etc, would probably be the "fast" way to do it. (for games that do have enough in RAM already this could just be a simple as drawing from VRAM to screen rect. For other games, it will be extract tilemap to internal VRAM buffer, then render it. Most games have static backgrounds or mostly static backgrounds so if needed this could even be offline processed into pngs or whatever and handled "SDD-1 patch" style.
And avoids issues such as
- where are you getting the extra VBlank time from without breaking frame and music sync?
- where are you getting the extra VRam for games that are single screen and using it all up ( IoT boss fight for example )
- where are you getting the extra time for Sprite fetch as you now draw more sprites per line and hence now have some/more dropout?
User avatar
FitzRoy
Posts: 144
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Target width for widescreen patches?

Post by FitzRoy »

I'm sorry, I heard a lot of words saying "don't use pure nearest-neighbor scaling with noninteger scale ratios". So don't do that. That's not a constraint, just you picking an arbitrary rationalization to justify a width of 480.
Did you just link to a blur filter and imply problem solved? Blurring is a problem substitute. The best default is the one that has the least forced visual tradeoffs. You can still stretch or zoomcrop or blur with 480 if you want.
Oziphantom wrote:It would be far easier to make external patches that run in the emulator, ala HD mods for NES games to do this than it would be to modify the ROMs.
They are external, but they'll come with the emulator. Art and music remakes are subjective and copyrighted, whereas this is primarily a technical enhancement. So there's no need to make people hunt for files and then figure out where to put them and name them. You would just dramatically reduce the popularity of the feature by doing that.

I can honestly see something similar happening with game bugs. Activate a checkbox, fix all the bugs in FF4 and FF6 without hard-patching the games? Yes please.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Target width for widescreen patches?

Post by psycopathicteen »

FitzRoy wrote:
I'm sorry, I heard a lot of words saying "don't use pure nearest-neighbor scaling with noninteger scale ratios". So don't do that. That's not a constraint, just you picking an arbitrary rationalization to justify a width of 480.
Did you just link to a blur filter and imply problem solved? Blurring is a problem substitute. The best default is the one that has the least forced visual tradeoffs. You can still stretch or zoomcrop or blur with 480 if you want.
Oziphantom wrote:It would be far easier to make external patches that run in the emulator, ala HD mods for NES games to do this than it would be to modify the ROMs.
They are external, but they'll come with the emulator. Art and music remakes are subjective and copyrighted, whereas this is primarily a technical enhancement. So there's no need to make people hunt for files and then figure out where to put them and name them. You would just dramatically reduce the popularity of the feature by doing that.

I can honestly see something similar happening with game bugs. Activate a checkbox, fix all the bugs in FF4 and FF6 without hard-patching the games? Yes please.
I clicked on the link and it turns out it only blurs 1 pixel between pixels, instead of the entire thing. If you're doing this for an HDTV you'll have 3 or 4 clean pixels per pixel, with 1 blurred pixel inbetween.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Target width for widescreen patches?

Post by tepples »

Oziphantom wrote:where are you getting the extra time for Sprite fetch as you now draw more sprites per line and hence now have some/more dropout?
Hardware-wise, extra time for background and sprite fetch is easy: run the PPU at one dot and fetch per 3 master clocks instead of 4. Or do what the TG16's 336-pixel mode does: allow only the ordinary number of sprites per line and just accept the increased dropout.
psycopathicteen wrote:I clicked on the link and it turns out it only blurs 1 pixel between pixels, instead of the entire thing. If you're doing this for an HDTV you'll have 3 or 4 clean pixels per pixel, with 1 blurred pixel inbetween.
This sounds like good old fractional bilinear interpolation, which you'll probably have to do anyway vertically when targeting 1080p.

My recommendation of expanding to 352x224 and then scaling while preserving NTSC Super NES PAR would produce the following horizontal scale factors for an FBI implementation:
  • 480p: 704/280*3/4 = 66/35 = 1.8857 by 2
  • 720p: 1280/280*3/4 = 24/7 = 3.4286 by 3
  • 1080p: 1920/280*3/4 = 36/7 = 5.1428 by 9/2 = 4.5
If you know that a particular HD display doesn't overscan, you can increase the FBI scale factor at the cost of cutting off a few rows of pixels at top and bottom.
  • 720p: Stretch a 320x206 pixel picture by 4 horizontally and 3.5 vertically. This adds 32 pixels to the left and right sides and cuts 9 pixels off the top and bottom.
  • 1080p: Stretch a 336x216 pixel picture by 40/7 = 5.7143 horizontally and 5 vertically. This adds 40 pixels to the left and right sides and cuts 4 pixels off the top and bottom.
With all these scaling options, both square and 8:7 PAR, there needs to be some negotiation between a widescreen-patched game and a clone console or emulator as to what expanded sizes a game can use and what sizes the hardware can produce.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Target width for widescreen patches?

Post by rainwarrior »

FitzRoy wrote:
lidnariq wrote:But more seriously, the more I think about this, the more I think this is something that should be decided on a hack-by-hack basis. It'd be a shame to discover that some games just can't get the desired "full" width, whatever that is.
That sounds terrible, we need to push for a standard as these patches are hard to make. The option should lead to consistent results and be as simple as checking a box. We should push for 480 or even 640 and then give zoomcrop options to effectively achieve narrower outputs. If you undercut yourself, you eliminate the possibility of running in 480, which has major benefits that I am trying to point out.
No, I don't think there's a need for a standard dimension at all. I don't think there's really much need to argue about pixel aspect ratios, or what the target resolution should be, TBQH. Whether or not game art was circular to begin width hardly matters, these hacks aren't going to be changing PAR, they're adding pixels. Besides, what's possible/practical will be very much decided on a per-game basis anyway.

For a game where this can work, you already have a map/background that can be extended to some arbitrary size. The point is to fill the screen. You extend as far as you can and then crop there. This concept easily adapts to different PAR options and different screen geometries.

It might matter a little bit if you wanted to move UI elements from their original location to the sides or coners of the HD screen, but wanting to do something like that in a game that you could do that to... there are so many constraints here, there's no way some standard could apply. Every game has different UI needs. In this respect, you have a "safe" region in the original screen area that everybody is guaranteed to have, and all visual content outside this region should be seen as optional. The whole problem becomes a really big "overscan".


As a suggestion though, perhaps the emulator should implement some new registers that return the host emulated screen dimensions in pixels? That would allow hacks to dynamically place UI elements or stuff like that (if this is really needed at all), and maybe also let those same hacks determine when widescreen emulation isn't available too, so they can fall back in some way. This might also provide a mechanism for the hack to tell the emulator "the screen can go as wide as XXX pixels", so that it does not try to over-extend the view if a game could only go so far.

E.g. You write "496, 240" to the widescreen control registers indicating your maximum pixel dimension, and then read back "398, 224" which lets you know what the emulator was able to provide. You otherwise do all the same things in the hack, but might use this information to relocate UI or something, if you need to.


BTW, I think it seems just as natural to want to extend the vertical pixel range as well. (Could be quite wonderful for assisting "atlas" style videos: example 1, example 2.)


Otherwise, good luck with the hacking I guess. For anyone wanting to do this, there's clearly a mountain of problems for you to solve. Easy to cherry-pick a screenshot that looks clean, but of course a video demonstration makes it really easy to spot the things that will need a lot of attention. In the long run you'll probably need quite a bit of extended register / interface support, and that would need a standard.
User avatar
FitzRoy
Posts: 144
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Target width for widescreen patches?

Post by FitzRoy »

The first widescreen patch for SNES is in the works courtesy of ocesse! Super Metroid it is:

https://www.youtube.com/watch?v=qsCauHvTiCg
https://mega.nz/#!x5hHyaoQ!3EILjgMAT88R ... _jDKfggF_U

Notes:
-Make sure sprites=unsafe in the settings, I don't think that was mentioned in the readme.
-Reminder: enemies don't appear until you explore a bit and grab the morph ball.
-The game suffers slowdowns and would benefit from overclocking, but hangs if you overclock it. Not sure how much hacking would be required to fix this.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Target width for widescreen patches?

Post by rainwarrior »

Neat!
Post Reply