0 users browsing Emulation. | 1 bot  
    Main » Emulation » SNES HD mode 7
    Pages: First Previous 1 2 3 Next Last
    BearOso
    Posted on 19-04-17, 17:38

    Post: #77 of 175
    Since: 10-30-18

    Last post: 1454 days
    Last view: 1454 days
    Posted by Screwtape
    > 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.

    My thought was it probably uses a different algorithm when you know the changes scanline-to-scanline are monotonic.
    nyanpasu64
    Posted on 19-04-17, 18:04
    Post: #37 of 77
    Since: 10-31-18

    Last post: 1193 days
    Last view: 1119 days
    Posted by BearOso
    My thought was it probably uses a different algorithm when you know the changes scanline-to-scanline are monotonic.
    https://imgur.com/a/aApu3Ba#qyWl994 Terranigma's upper blue thing looks glitchy, maybe because the algorithm assumes it's monotonic but it isn't.
    MamiyaOtaru
    Posted on 19-04-17, 18:06
    Post: #1 of 3
    Since: 04-17-19

    Last post: 2043 days
    Last view: 2043 days
    Posted by hunterk
    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 :)

    tried it out and it looked a little funky.



    shooting in the dark I wondered if it was because nothing was scaled up 8x on my screen. Edited super-8xbr-3d-pass0.fs and super-8xbr-3d-pass1.fs changing #define XBR_RES 8.0 to #define XBR_RES 4.0 and it looked like



    Rather nice, if a tad blurry somehow :)
    hunterk
    Posted on 19-04-17, 19:21 (revision 1)
    Post: #24 of 60
    Since: 10-29-18

    Last post: 1645 days
    Last view: 1567 days
    		Ok, I just pushed up a 4x version you can try, if you like :)

    However, it's possible I'm misunderstanding how it works altogether. For anyone who knows: what size is the final framebuffer that's coming out? it's not still 512x480, is it? That is, is it scaling up with the mode7?
    nyanpasu64
    Posted on 19-04-17, 22:05 (revision 3)
    Post: #38 of 77
    Since: 10-31-18

    Last post: 1193 days
    Last view: 1119 days
    		xbrz is strictly better than xbr.

    Windows 10 Magnifier added xbr (or a very similar upscaler). When you zoom in on ClearType colored text, the edges break down spectacularly. The same fragmented artifacts appear in ScalerTest.exe xbr.

    xbrz handles colored edges much better than xbr, with nearly no artifacts.

    I'm on Linux, but I can take ScalerTest (not Magnifier) screenshots if anyone wants.

    (The difference is more subtle than I remembered, xbr is not as bad and xbrz isn't perfect.)

    xBR https://kayo.moe/5dG7cBao.png
    xBRZ https://kayo.moe/OELJLahD.png

    The most notable differences are the title bar M, 800 and %, and Views "ew".
    Duck Penis
    Posted on 19-04-17, 23:04
    Stirrer of Shit
    Post: #216 of 717
    Since: 01-26-19

    Last post: 1766 days
    Last view: 1765 days
    Posted by jimbo1qaz
    xBR https://kayo.moe/5dG7cBao.png
    xBRZ https://kayo.moe/OELJLahD.png

    Those links don't appear to work.
    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.
    nyanpasu64
    Posted on 19-04-17, 23:21 (revision 1)
    Post: #39 of 77
    Since: 10-31-18

    Last post: 1193 days
    Last view: 1119 days
    Posted by sureanem
    Posted by jimbo1qaz
    xBR https://kayo.moe/5dG7cBao.png
    xBRZ https://kayo.moe/OELJLahD.png

    Those links don't appear to work.

    works for me, including in private browsing mode.

    I've uploaded to Dropbox too:

    https://www.dropbox.com/s/ywuctnjoyxu7ujo/magnifier-xbr4.png
    https://www.dropbox.com/s/eg54tt6z7c53ivn/magnifier-xbrz4.png
    Kawaoneechan
    Posted on 19-04-17, 23:57
    Chocolate Enthusiast

    Post: #204 of 599
    Since: 10-29-18

    Last post: 199 days
    Last view: 12 hours
    		Oof that's painful.
    Screwtape
    Posted on 19-04-18, 02:01
    Full mod

    Post: #224 of 443
    Since: 10-30-18

    Last post: 1104 days
    Last view: 175 days
    Posted by hunterk
    For anyone who knows: what size is the final framebuffer that's coming out? it's not still 512x480, is it? That is, is it scaling up with the mode7?

    There's a slider so you can pick your output resolution: 1× (disabled), 2× (480p), 3× (720p), 4× (960p). It defaults to 960p.
    The ending of the words is ALMSIVI.
    Screwtape
    Posted on 19-04-18, 03:11
    Full mod

    Post: #225 of 443
    Since: 10-30-18

    Last post: 1104 days
    Last view: 175 days
    		Somebody in the Reddit thread posted screenshots of Super Soccer, which happens to be another good example of what the Assume 3D Perspective option does.
    The ending of the words is ALMSIVI.
    Near
    Posted on 19-04-18, 07:11 (revision 1)
    Burned-out Genius Developer
    Post: #36 of 51
    Since: 10-30-18

    Last post: 1422 days
    Last view: 1346 days
    		I implemented DerKoun's work, and I understand it now.

    By default it just interpolates between two real scanlines nearest to the virtual scanline being output.

    The perspective option instead scans up and down the frame to find the first and last mode 7 scanline, and takes the matrix transform parameters from there. So yeah, HDMA effects that do something other than a standard affine-style transformation won't work, but most games do that so it's usually fine.

    I think the perspective option can be enhanced in the future to detect when a frame isn't really in perspective, and to disable the option for said frames. Could even design it to split the frame into multiple chunks, so eg Terranigma can be made to look good. Probably won't be trivial, though. Certainly it's above my head, mathematically.

    Also, upon implementing this, I can see that unfortunately this will be a nightmare for other emulators to implement, especially for FPGAs.

    The only reason this is possible is because of my new parallel PPU renderer that builds up an entire frame worth of scanlines (I/O registers and palette RAM.) If you don't implement this, you won't be able to do the critically important perspective correction. You can probably manage the non-perspective variant by averaging between the current and previous scanline mode 7 parameters, though. Then it's just a matter of some gruesome code to scale up mixed-mode backgrounds and sprites to your larger canvas.
    Screwtape
    Posted on 19-04-18, 10:53 (revision 1)
    Full mod

    Post: #226 of 443
    Since: 10-30-18

    Last post: 1104 days
    Last view: 175 days
    		I got it to crash. Steps to reproduce:

    - Boot Super Mario Kart
    - Start a 1P time trial as Mario, on Mario Circuit 1
    - when Lakitu shows with the traffic light, open Emulation settings, turn the scale from 240p up to 480p and untick "Perspective correction"

    Backtrace:

    terminate called after throwing an instance of 'nall::array<nall::Natural<15u> [256]>::operator[](unsigned int)::out_of_bounds'

    Thread 1 "bsnes" received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    (gdb) bt
    #0  0x00007ffff61698bb in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
    #1  0x00007ffff6154535 in __GI_abort () at abort.c:79
    #2  0x00007ffff6570983 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #3  0x00007ffff65768c6 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #4  0x00007ffff65759d9 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #5  0x00007ffff65762d5 in __gxx_personality_v0 () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #6  0x00007ffff6326e33 in  () at /lib/x86_64-linux-gnu/libgcc_s.so.1
    #7  0x00007ffff6327391 in _Unwind_RaiseException () at /lib/x86_64-linux-gnu/libgcc_s.so.1
    #8  0x00007ffff6576b27 in __cxa_throw () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #9  0x000055555568bc6d in SuperFamicom::PPUfast::Line::renderMode7HD(SuperFamicom::PPUfast::IO::Background&, unsigned int) ()
    #10 0x000055555568bfd5 in SuperFamicom::PPUfast::Line::renderMode7(SuperFamicom::PPUfast::IO::Background&, unsigned int) ()
    #11 0x000055555568c7c3 in SuperFamicom::PPUfast::Line::renderBackground(SuperFamicom::PPUfast::IO::Background&, unsigned int) ()
    #12 0x000055555568f79d in SuperFamicom::PPUfast::Line::render() ()
    #13 0x000055555568fa90 in SuperFamicom::PPUfast::Line::flush() [clone ._omp_fn.0] ()
    #14 0x00007ffff633de0f in GOMP_parallel () at /usr/lib/x86_64-linux-gnu/libgomp.so.1
    #15 0x0000555555689998 in SuperFamicom::PPUfast::Line::flush() ()
    #16 0x000055555568ff67 in SuperFamicom::PPUfast::writeIO(nall::Natural<24u>, nall::Natural<8u>) ()
    #17 0x00005555556966e0 in nall::function<void (nall::Natural<24u>, nall::Natural<8u>)>::member<SuperFamicom::PPUfast>::operator()(nall::Natural<24u>, nall::Natural<8u>) const ()
    #18 0x000055555567722f in SuperFamicom::CPU::dmaRun() ()
    #19 0x0000555555677af8 in SuperFamicom::CPU::read(nall::Natural<24u>) ()
    #20 0x000055555574c56c in Processor::WDC65816::instructionResetP() ()
    #21 0x000055555574e317 in Processor::WDC65816::instruction() ()
    #22 0x000055555567572f in SuperFamicom::CPU::main() ()
    #23 0x0000555555675907 in SuperFamicom::CPU::Enter() ()
    #24 0x0000555555631420 in crash ()
    #25 0x0000000000000000 in  ()


    On the track-select screen, I can switch between resolutions and toggle "Perspective correction" with impunity. Once I reach the actual time trial, I can still switch resolutions but the moment I touch "toggle perspective", boom!

    > I think the perspective option can be enhanced in the future to detect when a frame isn't really in perspective, and to disable the option for said frames. Could even design it to split the frame into multiple chunks, so eg Terranigma can be made to look good. Probably won't be trivial, though. Certainly it's above my head, mathematically.

    How about using a moving average of the parameters to detect perspective changes?

    - from the third to the last scanline, extrapolate from the previous two scanlines to predict the current scanline
    - if the predicted value of any parameter is (configurable threshold) different from the recorded value, this scanline is the beginning of a new chunk
    - once the screen is divided into chunks, treat each chunk like the current code treats the whole screen
    - for interpolated scanlines between chunks, you could just leave them black, or use the extrapolated values from the previous two scanlines, or just treat that as a very tiny chunk and interpolate between the previous and next scanlines.

    You don't want to make the threshold too small, or you'll reproduce the rounding errors of the original hardware too closely. You don't want to make the threshold too large, or a "curved" effect like Terranimga would wind up broken into straight segments. Hopefully there's some sensible value that works acceptably well for all games.

    EDIT: /u/geearf on Reddit points out that the bsnes makefile has copied higan's "do not run make install as root" message, but (unlike higan) bsnes does not actually have any writable resources, so it should be fine to "make install" as root.
    The ending of the words is ALMSIVI.
    BearOso
    Posted on 19-04-18, 16:12

    Post: #79 of 175
    Since: 10-30-18

    Last post: 1454 days
    Last view: 1454 days
    Posted by byuu

    I think the perspective option can be enhanced in the future to detect when a frame isn't really in perspective, and to disable the option for said frames. Could even design it to split the frame into multiple chunks, so eg Terranigma can be made to look good. Probably won't be trivial, though. Certainly it's above my head, mathematically.

    I'd just check if any of the parameters of the normal change sign. You create a new interpolation point on that scanline.


    Also, upon implementing this, I can see that unfortunately this will be a nightmare for other emulators to implement, especially for FPGAs.

    Snes9x could turn off the PPU and DSP output and run ahead to fetch all the parameters needed then warp back to the first scanline. The extra CPU cost would easily be dwarfed by the overhead of the extra rendering.

    However, I'm personally not up for the challenge at the moment. Bilinear filtering looks particularly easy to bring back, so I might start with that.
    nyanpasu64
    Posted on 19-04-18, 18:32
    Post: #40 of 77
    Since: 10-31-18

    Last post: 1193 days
    Last view: 1119 days
    Posted by BearOso
    I'd just check if any of the parameters of the normal change sign. You create a new interpolation point on that scanline.
    That may fail to detect that soccer game, since it goes from zero distortion to nonzero, without a strict sign change? IDK
    MamiyaOtaru
    Posted on 19-04-19, 08:41 (revision 1)
    Post: #2 of 3
    Since: 04-17-19

    Last post: 2043 days
    Last view: 2043 days
    		with DerKoun's beta 3 in Mario Kart the internal resolution (if that makes sense) is now different on the track than it is on the title screen and menus. So Hyllian's Super-xbr-3d (meant to smooth 2d elements like sprites while ignoring a 3d background) works on the track (see my screenshots earlier on page 2) but makes the menus garbled. Conversely regular shaders like scalefx work in the menus but not on the track. In the initial beta the menus were at the same internal resolution, and super-xbr-3d could handle the whole game.

    tl;dr internal resolution increases when mode7 is in use but not otherwise, but this confuses shaders. Could it stay consistent? Allows for http://chattypics.com/files/superxbr_v6ho1f2s4w.png
    BearOso
    Posted on 19-04-19, 16:55

    Post: #80 of 175
    Since: 10-30-18

    Last post: 1454 days
    Last view: 1454 days
    Posted by BearOso

    However, I'm personally not up for the challenge at the moment. Bilinear filtering looks particularly easy to bring back, so I might start with that.

    Ugh. I went back to look at the bilinear filtering, and it's just not good. I won't be doing that.
    Near
    Posted on 19-04-19, 23:19 (revision 1)
    Burned-out Genius Developer
    Post: #37 of 51
    Since: 10-30-18

    Last post: 1422 days
    Last view: 1346 days
    On the track-select screen, I can switch between resolutions and toggle "Perspective correction" with impunity. Once I reach the actual time trial, I can still switch resolutions but the moment I touch "toggle perspective", boom!


    Very strange. I'll look into it, thanks.

    with DerKoun's beta 3 in Mario Kart the internal resolution (if that makes sense) is now different on the track than it is on the title screen and menus.


    That one was my change. It's the same way hires and interlace modes work, the output resolution is the smallest size that will fit the game content. This is a fairly important speedup (outputting 4K pixels in *software* is going to be intensely painful even without any emulation at all), and it's also necessary to output at 256x240 for most shaders to work.

    It does look bad when changing modes, but the alternative is relegating 90% of hunterk's quark shader repository to non-working status.

    If we were willing to kill all but the OpenGL driver (which lacks exclusive mode support), I could include an option to upscale the video to a set size using point sampling, then apply shaders to output the final image. Shaders themselves could also be updated to be given hints as to the underlying resolution as well, but every single one would have to be updated.

    Ugh. I went back to look at the bilinear filtering, and it's just not good. I won't be doing that.


    Ah, darn =(

    Well, this is just a gimmick after all. It also can't really work with mode 7 mosaic by design, and the 3D perspective correction option is hit-or-miss depending on the game. Makes for some amazing screenshots, though.
    MT
    Posted on 19-04-22, 08:56

    Post: #9 of 9
    Since: 02-27-19

    Last post: 2043 days
    Last view: 1930 days
    		Sorry if this was already asked and answered somewhere, but what does the 7 digit mean in the mode title? Thanks.
    Kawaoneechan
    Posted on 19-04-22, 09:35
    Confound these ponies, they drive me to drink.

    Post: #205 of 599
    Since: 10-29-18

    Last post: 199 days
    Last view: 12 hours
    Posted by MT
    Sorry if this was already asked and answered somewhere, but what does the 7 digit mean in the mode title? Thanks.
    It's a screen mode number. On the SNES, various screen modes allow different amounts of backgrounds and color depths per background. Mode 7 specifically is the only one that allows affine transformation at the cost of flexibility, though you wouldn't think so when you can just switch modes mid-frame.

    https://www.youtube.com/watch?v=5SBEAZIfDAg
    https://www.youtube.com/watch?v=3FVN_Ze7bzw

    It's such a typical effect that any game with a flat map projected into perspective like Super Mario Kart and F-Zero do, no matter what system the games run on, it's still called "Mode 7", even if that's a completely different video mode on that system. For example, Wacky Wheels has a "mode 7 effect" (being a kart racer), even though on a PC, mode 7 isn't even graphical.
    creaothceann
    Posted on 19-04-22, 10:24 (revision 1)

    Post: #125 of 456
    Since: 10-29-18

    Last post: 47 days
    Last view: 4 days
    Posted by Kawa
    screen mode

    To be more precise, it's a 'background (decoding) mode'. It tells the SNES how to fetch and translate the graphics for the background layers, and can be specified per line. Sprites are not affected.

    There are several screen modes, depending on some bits:
    - 224 or 239 lines per field (basically, NTSC or PAL)
    - progressive (default) or interlaced fields (most useful for BG modes 5 and 6)
    My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
    Pages: First Previous 1 2 3 Next Last
      Main » Emulation » SNES HD mode 7
      Powered by AcmlmBoard XD, version 2.2.3-Lambda
      By Kawa, Arisotura, Nadia, et al
      AcmlmBoard © Jean-François Lapointe
      Page rendered in 0.176 seconds with 25 MySQL queries.
      This does not actually go there and I regret nothing.