Near |
Posted on 19-04-16, 20:51 (revision 3)
|
Burned-out Genius Developer
Post: #32 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
Okay so this absolutely blew up last night. https://www.reddit.com/r/emulation/comments/bdltmo/hd_mode_7_mod_for_bsnes_v1071_beta_1/ https://www.resetera.com/threads/bsnes-emulator-mod-allows-for-hd-rendering-of-mode7-games.111715/ https://www.pcgamer.com/this-snes-emulator-mod-makes-mode-7-graphics-hd-with-amazing-results I implemented hires mode 7 in bsnes, where I render at double resolution, which is the same thing ZSNES and Snes9X used to do. It didn't make a large difference, so I just filed it as a novelty option and moved on. u/DerKoun on Reddit came along and upped it to 16x resolution for jaw-dropping results: Frankly, I'm stunned we didn't realize this level of detail was possible for 20+ years. So, I intend to offer this in bsnes, but I'm curious if Snes9X and/or Mesen-S are going to be interested or not. I know Snes9X recently removed the feature, so ... maybe it's too soon? But if others want to implement this, I think we should coordinate on what we name all of the various options and how they work, mathematically, so we can provide a consistent user experience instead of a mass of confusion. I won't hold back anyone's progress: if someone comes up with something cool, I'll implement it as well. Current considerations: * supersampling: if we scale the resulting image back down, it makes the pixel resolution match better without causing too great a disparity between sprite pixel sites and the background detail. Example: https://i.imgur.com/DTBoOTN.gif * prescaling: we can perform filtering like HQ2x onto the mode 7 background first to smooth the jaggedness of the output, but that probably won't matter unless we go crazy and output at 4K mode. * interpolation: we can interpolate on the output pixels to smooth things out, and also introduce more than 256 colors from the source image in doing so. * maximum scaling factor: do we stop at 1024x1024, or go up even higher? * perspective correction: affine texture mapping (eg what mode 7 actually is) has a really obvious problem with distortion. We could offer an option to correct for this. Example: https://en.wikipedia.org/wiki/Texture_mapping#/media/File:Perspective_correct_texture_mapping.jpg If no one's interested in coming up with some standard terms and features for this, that's okay too, and I'll just experiment on my own for now. |
hunterk |
Posted on 19-04-16, 20:57
|
Post: #22 of 60
Since: 10-29-18 Last post: 1642 days Last view: 1563 days |
I think having a pre-set super-sampling option is a slam dunk. That will allow people using CRT shaders to not need a pre-pass that sets the original res. Re: res-cap, you get diminishing returns with each jump, and I think there's some hoodoo about nyquist that mathematically says there's no point beyond ~16x (and barely so at 8x). HQx/xBR would be great, but it doesn't store the texture as one big image, does it? If not, those algos are going to have problems at the seams. It's not the worst thing ever, but you'll see it. Fixing the distortions seems like a good plan to me. |
Broseph |
Posted on 19-04-16, 21:13
|
Post: #75 of 166 Since: 10-29-18 Last post: 1561 days Last view: 1238 days |
So if I got this right what we're seeing in the higher res pics is effectively the original artwork/tile map or whatever before they get scaled down by the hardware somehow? Pretty damn impressive either way. |
BearOso |
Posted on 19-04-16, 21:20
|
Post: #75 of 175 Since: 10-30-18 Last post: 1450 days Last view: 1450 days |
Posted by byuu Actually, it disappeared with anomie's tile renderer rewrite in 1.50 or so. And I believe it was only bilinear filtering towards the end. Supersampling sounds like a good idea. I liked the way Themaister did it with the PSX. |
Duck Penis |
Posted on 19-04-16, 21:30
|
Stirrer of Shit
Post: #213 of 717 Since: 01-26-19 Last post: 1763 days Last view: 1761 days |
Posted by Broseph Well, it doesn't get scaled down, just subsampled–it takes one pixel and uses it to fill a wider area, rather than taking an average which is what usually happens when you scale down. So even if you'd scale it down to native resolution in the end, it would still look "better" than naïve/fast subsampling. (Better is subjective–in some games like F-Zero, "proper" scaling in my opinion looks like trash because the graphics were drawn so they'd look good with "bad" subsampling) There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
Broseph |
Posted on 19-04-16, 21:58 (revision 1)
|
Post: #77 of 166 Since: 10-29-18 Last post: 1561 days Last view: 1238 days |
Posted by sureanem Got it. Thanks for the explanation. Too bad there's (least I'm assuming) no way to mod an SNES to do the same. |
wareya |
Posted on 19-04-16, 22:02
|
Post: #58 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Posted by hunterk Nah, that's just the point where it stops mattering with "normal" signals because they contain finite amounts of information that tend not to have fine-scale patterns stay stable and in-phase across large regions. Pathological signals can alias no matter how high you oversample. Plus if you're not using a brick wall lowpass then nyquist-shannon sampling theorem doesn't really play into it. |
creaothceann |
Posted on 19-04-16, 22:03
|
Post: #119 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
The (s)nesdev thread should be linked here for the record too, imo: https://forums.nesdev.com/viewtopic.php?f=12&t=18712 My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
Near |
Posted on 19-04-17, 00:55
|
Burned-out Genius Developer
Post: #33 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
Yeah I wanted both BearOso and Sour to see it, and they're on different boards generally, so ... why not. > HQx/xBR would be great, but it doesn't store the texture as one big image, does it? It is one big tilemap, 1024x1024. The complication against just throwing it into OpenGL (yuck) is that it doesn't work like a standard affine texture mapping where you just give 2D vertexes for all four corners to get your output image, the SNES games update the mode 7 parameters on every scanline during HDMA. When it comes to my own hires, all I'm doing is giving twice the fractional bits to run along the horizontal axis. Since the screen is 256x240, the result is you pull more underlying detail out. But say you're really zoomed in and only viewing a small portion of the screen, now the smaller portion has to be stretched to fill the screen, and at this point, HQ2x would be beneficial in the same way mip-mapping is. At least in theory. |
Screwtape |
Posted on 19-04-17, 02:13
|
Full mod
Post: #221 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
I was reading the Reddit thread, and apparently for games that don't just project a single square (like Super Castlevania has that inside-a-barrel section) you need to turn off an option named something like "Optimize for 3D perspective", and people suggest that it's actually an option from base bsnes, not an option added by the HD patch. However, I can't see such an option in my bsnes v107.1 build, so I'm not quite sure what's going on. > It didn't make a large difference, so I just filed it as a novelty option and moved on. I guess you were doubling the resolution along the already-higher-resolution axis, improving the best-case and average-case while the worst-case stayed the same. Although it would be more of a hack than double-res output, quadruple-res output (i.e. hi-res, interlaced) might have been kind of cool. Not as cool as 16× output, but on the other hand I guess 16× output implies 16× software scaling, and that's *not* cool, especially if we're talking about a CPU sitting directly on my lap. The ending of the words is ALMSIVI. |
BearOso |
Posted on 19-04-17, 02:40
|
Post: #76 of 175 Since: 10-30-18 Last post: 1450 days Last view: 1450 days |
There’s nothing 3D related in bsnes, so there’s no way that’s an existing option. As far as affine transforms, I don’t think it’s a concern. For one, it’s not using triangles, so you’re not interpolating on two separate primitives. Second, it looks like most games are already taking depth into consideration with the transform parameters. I don’t feel the layman’s explanation images floating around adequately explain the method. It’s literally just sampling at a higher resolution, not scaling. HQx would need to have tile adjacency information when sampling, as well as sampling many more times, but I think that would really complicate things. The hardest part now is just dealing with the higher resolution layer in combination with the other ones. |
Near |
Posted on 19-04-17, 03:25 (revision 1)
|
Burned-out Genius Developer
Post: #34 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
> "Optimize for 3D perspective", and people suggest that it's actually an option from base bsnes Yeah I don't know what that's about, it's not an official bsnes feature. > For one, it’s not using triangles, so you’re not interpolating on two separate primitives. Ooooooooh, I get it now. Sorry. My mind's a bit muddled from trying to emulate 25+ systems and not touching this code for a while. Embarrassing >_> > HQx would need to have tile adjacency information when sampling The idea in my mind was, you have a 128x128 tilemap, so you fuse the whole tilemap together into one big 1024x1024 image. Then you can HQ2x that. Then if the screen is zoomed in on a smaller portion of it, it should help remove some of the remaining jaggedness we're seeing. I am aware that "HQ2x a 1024x1024 image" is going to be one hell of a demanding operation, so I don't expect this to work on games that update the tilemap often. It'd probably even cause FPS dips doing it a single time even with OpenMP. I also expect this approach to fall on its ass for any mode 7 scene that isn't literally just a simple rotozoomed quad (eg Hyperzone.) But maybe the entire idea is nonsense. > The hardest part now is just dealing with the higher resolution layer in combination with the other ones. I also haven't looked at the code yet, but my thought was to have an entirely separate PPU renderer for HD mode 7, that would gut features like EXTBG and interlace that aren't used in mode 7 by licensed games anyway. It would also lack BG rendering, so now you just have the mode 7 layer, sprites, windows, and color math to worry about. It's not gonna be fun, of course. But the results are breathtaking enough (especially Dragon Quest 3, good lord) to warrant the work, probably. We'll see. I need to undertand what his 3D perspective setting does now. |
Screwtape |
Posted on 19-04-17, 04:49 (revision 1)
|
Full mod
Post: #222 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
> I need to undertand what his 3D perspective setting does now. I'm guessing it's related to the way it interpolates new scanlines between each row. If you want to interpolate HD scanlines between two SNES scanlines, you need to know the configuration the game used for the upper and lower SNES scanlines to do the interpolation. However, that would require letting SNES emulation advance to the next scanline before you've drawn the previous one, and that might have implications for sprite rendering, etc. Instead, when you're rendering an interpolated scanline, you need to extrapolate the settings based on the previous two scanlines, and there are probably different ways to extrapolate depending on whether you assume it's a 3D perspective or not. EDIT: I made an imgur gallery to demonstrate the effect of the "Optimize psuedo 3D perspective" option. The ending of the words is ALMSIVI. |
creaothceann |
Posted on 19-04-17, 05:32
|
Post: #120 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Posted by byuu EXTBG is used by a few titles, for example SMW's bowser fight (iirc) and Contra 3. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
CaptainJistuce |
Posted on 19-04-17, 06:13
|
Custom title here
Post: #409 of 1164 Since: 10-30-18 Last post: 63 days Last view: 11 hours |
Posted by byuuNow I'm curious what Hyperzone does that is unusual. It doesn't APPEAR to be doing anything particularly interesting. --- In UTF-16, where available. --- |
Screwtape |
Posted on 19-04-17, 07:08
|
Full mod
Post: #223 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
> Now I'm curious what Hyperzone does that is unusual. My guess: It changes the tilemap every couple of frames, which would require reapplying HQ2x to the 1024×1024 Mode 7 background, bringing the PC CPU to its knees. The ending of the words is ALMSIVI. |
creaothceann |
Posted on 19-04-17, 09:34
|
Post: #121 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Hyperzone only changes the color palette (every time you see some white flashing beyond the track). Easy for the hardware, but the emulator would have to filter a new image. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
Near |
Posted on 19-04-17, 14:14 (revision 3)
|
Burned-out Genius Developer
Post: #35 of 51 Since: 10-30-18 Last post: 1419 days Last view: 1342 days |
Geez, I am really getting all of the details wrong on this. It's been too long, too many systems since I implemented all of this. Okay yeah, so they're using EXTBG mode to get the priority bit. I was thinking of the mosaic 'glitch' where you can reveal very obvious and extreme differences between BG1 and BG2. So what I need to do is drop the ability to use both BGs at the same time, and instead just render one layer. Interlacing can definitely go, at least. But yeah, I am still going to need an entirely separate mode 7 PPU renderer, so that the upscaling support of sprites and windows doesn't affect performance when not in use. Then again, if any games do a mode 7 - > mode N change mid-scanline for eg a text box, then I am screwed. > Hyperzone only changes the color palette Again, I'm an idiot >_> Yeah, the idea to upscale the underlying 1024x1024 screen won't work if the game changes the palette every frame. Well, there's probably something we can do with the interpolation besides nearest-neighbor that won't be too costly. Maybe a simple scale2x would work. It works amazingly well on certain patterns, like the bottom bar in Super Mario Bros. 3 (All-Stars.) > If you want to interpolate HD scanlines between two SNES scanlines, you need to know the configuration the game used for the upper and lower SNES scanlines to do the interpolation. However, that would require letting SNES emulation advance to the next scanline before you've drawn the previous one, and that might have implications for sprite rendering, etc. Oh boy, if that's the case then I sure lucked out with making the multi-threaded PPU recently. It caches all the screen stuff (registers, palette, etc) each scanline so you can draw everything at the end of the frame at once. There is a limitation where this will get split into batches if a game turns the screen off mid-scanline for VRAM writes, but in practice there isn't a game that does this. They'll turn it off at the top or bottom edges to get more Vblank time, of course, and that doesn't matter, the end result is the flush() call still has an entire frame worth of scanlines at once. However, that's bad news for getting this support into Snes9X and Mesen-S. They'd have to also adapt a line caching system like this. Gonna go out on a limb and guess Snes9X won't want to use my PPU core, nor do I really want to license that one to be usable in closed source forks ... tricky. |
creaothceann |
Posted on 19-04-17, 15:35 (revision 1)
|
Post: #122 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
Posted by byuu Maybe the upscaling can be done with 8-bit bitmap data? Of course every group of lines of the emulator output has to use its own palette, in case the game changes it between lines. My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
hunterk |
Posted on 19-04-17, 15:40
|
Post: #23 of 60
Since: 10-29-18 Last post: 1642 days Last view: 1563 days |
If anyone is interested, I just ported over hyllian's Super-8xBR-3D-6p shader, which should smooth out pixels that have been upscaled by 8x (that is, the stuff that's *not* hires mode7). It's in the quark shader repo. I haven't actually tested it with any mode7 stuff, just verified that it compiles properly and smooths out an 8x scaled image (tested via aliaspider's shader test program), so if anyone tries it, I'd be interested in seeing screenshots :) |