Target width for widescreen patches?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
byuu
Posts: 1544
Joined: Mon Mar 27, 2006 5:23 pm
Contact:

Re: Target width for widescreen patches?

Post by byuu » Mon Nov 18, 2019 7:44 pm

I suspect we'll need to rethink the overclocking method in that case, because overclocking is going to be the key way with which to compensate for the added load of processing the extra tiles.

Still, very promising work so far!

Sour
Posts: 767
Joined: Sun Feb 07, 2016 6:16 pm

Re: Target width for widescreen patches?

Post by Sour » Mon Nov 18, 2019 8:48 pm

I don't know where bsnes adds its extra scanlines, but in my original testing I did find Metroid to be one of the games that tends to freeze rather quickly if you put the scanlines before the NMI. After NMI, it handled up to ~400 extra scanlines, which should be enough to take care of most slowdowns (since that's essentially 250% clock speed). I would imagine the freeze is probably something rather specific in Metroid's code and might not be too hard to fix, either.

byuu
Posts: 1544
Joined: Mon Mar 27, 2006 5:23 pm
Contact:

Re: Target width for widescreen patches?

Post by byuu » Tue Nov 19, 2019 2:56 am

bsnes uses before, but this is yet another detail that we really shouldn't be expecting users to know about.

My intention is to work on a SHA256-lookup database for games that encodes all kinds of information:
* does the game not work if there's a regular controller in port 2?
* does the game only work with a mouse in port 1?
* do we need a custom raster position for a scanline renderer to not show erorrs?
* is this a prototype with a bad header? in which case, what should a corrected header be?
* is there a patch for any game-breaking bug?
* are any of the common speed hacks (scanline renderer, sample-based DSP syncing) incompatible with this game?
* is this a ROM hack that needs ZSNES emulation (eg shadow APU RAM) to work?
* what's the maximum number of run-ahead frames that are safe for this title?
And so forth.

Idea is for it to be extensible markup, so an infinite number of fields can be added for any game.
So we could easily add "should overclocking happen before or after NMI?" to the list.
If it's something you're interested in for Mesen-S, let me know and I'll include you in format discussions.
I would imagine the freeze is probably something rather specific in Metroid's code and might not be too hard to fix, either.
Yeah, that's what I was thinking. The game is freezing, so ... why? If we know, we might be able to get away with only having to sync before NMI for all titles. In any case, I'll look into it once my mini-vacation is over ^-^;

User avatar
FitzRoy
Posts: 125
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Target width for widescreen patches?

Post by FitzRoy » Tue Nov 19, 2019 4:56 am

Due to no real guidance outside of Derkoun's experimental fork, the patch author seems to have designed his patch for the vertically cropped resolution of 384x216 (One fifth of 1080p). You can see that in his options screen on youtube. His patch doesn't work on 480 (One fourth of 1080p), even though it probably could. I voiced my concerns about this in the first post, but people seemed to think that hackers were just going to hack to the limit because why not.

Everything has a fullscreen downside, and 384x216's is cropping. The damage is minimal in SM because the HUD is well padded. But some titles have their huds and message boxes right up near the edge. You'll always be clipping into ground/sky, but possibly also the hud. Try running Super Castlevania IV in this resolution and you'll see the hud get clipped. In DKC, you might miss some bonus stage barrels that were designed to just barely be visible at the tops or bottoms of the screen.

My suggestion is to support both like this:
Image

And I'd suggest bundling the patches (and their potentially needed configuration files) somewhere normal users won't mess with them or try to mix them with other patches. And of course, credit patch authors somewhere.
Image

Oziphantom
Posts: 809
Joined: Tue Feb 07, 2017 2:03 am

Re: Target width for widescreen patches?

Post by Oziphantom » Tue Nov 19, 2019 6:51 am

are there any SNES side registers added so we can "stop widescreen" on layer 3 programatically. I had a quick look at Harvest Moon, and its mostly fine and dandy until a text box shows up, or the title screen appears, to which you get bad mirroring. Would probably be simple enough to toggle layer 3 at these points. You don't always want layer 3 as the weather effects are on it.

tepples
Posts: 21880
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Target width for widescreen patches?

Post by tepples » Tue Nov 19, 2019 7:01 am

If you're not already using the window, you can probably use it to clip your text boxes to x=2-254.

lidnariq
Posts: 9129
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Target width for widescreen patches?

Post by lidnariq » Tue Nov 19, 2019 11:45 am

How does this Super Metroid widescreen patch (+DerKoun's fork) handle the windowing registers? The windowing registers are used in several places (super bombs, x-ray visor) and I'm curious what it looks like ... but can't summon the energy to replay far enough to find out.

creaothceann
Posts: 217
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Target width for widescreen patches?

Post by creaothceann » Tue Nov 19, 2019 2:59 pm

You'd just have to watch the ship approaching the space station.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

Post Reply